Vous n'êtes pas identifié(e).
Pages : 1
Oups... Nous étions avec MySQL jusqu'à présent... Et pas de problèmes de ce type en tout cas...
Par contre notre gestion des VUES nous est indispensable du fait de l'utilisation d'1 table générique...
N'y aurait-il pas quelques exemples rapides pour nous permettre de passer ce cap ? Je ne mesure pas l'ampleur du trigger INSTEAD OF, je suis novice...
J'espère y parvenir avec quelques bons conseils et approfondir la question ensuite...
Merci
Bonjour, nous tâchons d'utiliser des VUES afin de communiquer avec notre base de données sous PostGreSQL et différents logiciels...
Nos structures et la maintenance de notre base de données est assurée via le logiciel NAVICAT v8...
L'interface de ce logiciel est sympa, et nous aura permis d'avancer assez vite dans la mise en place de notre application...
Par contre, depuis que nous avons introduit la notion des VUES, l'accès à notre VUE est en lecture seule, alors que la table reste parfaitement accessible...
Nous sommes bloqués...
Que faire pour que la VUE soit déclarée en LECTURE-ECRITURE et MISE à JOUR ? Quelle est cette astuce ?
Vous remerciant à tous
Bonjour rjuju,
Je vous confirme que mon problème de verrou provenait de la définition de mes variables numériques au format FLOAT8...
C'est incroyable mais je suis passé avec NUMERIC 24/5 est les réservations des enregistrement pas d'autres utrilisateurs virtuels n'apparaissent plus...
Je vous remercie de vos recherches...
A cela, je dois rajouter que le driver ODBC utilisé, la toute dernière version téléchargée, pose quelques problèmes de fonctionnement avec ACCESS. il nous oblige à des aménagements des formulaires et requêtes, avec des paramètres trop contraignants comme ceux que j'évoquais dans mon message du 1/9/12 - 18H15
Nous quittons alors les formidables facilités que nous offre ACCESS pour la mise à jour de données...
A présent, je jongle, et j'applique des commandes SQL directes pour passer outre certains verrous d'enregistrements lors de mises à jour de requêtes en cascade avec des tables liées...
Je vais néanmoins exécuter votre requête système au moment où je lance ma requête telle que je l'avais initialement... Si quelques chose pouvait en ressortir...
Cela signifie que je permets au système de modifier toutesl les tables rattachées dans la requete, et non plus la seule table primaire...
C'est dangereux... Et je me bloque les multiples possibilités offertes par Access qui pilote lui même ce type de possibilité
J'ai pu avancer dans mes blocages... Figurez-vous que j'utilisais FLOAT8 dans la définition de mes variables numériques au lieu de NUMERIC...
Dés lors, je n'ai plus d'ENREGISTREMENT RESERVES PAR 1 AUTRE UTILISATEUR...
Il me reste à présent seulement la gestion de mes REQUETES, qui continuent d'être en LECTURE SEULE...
Si vous connaissez ACCESS, je suis obligé pour passer de décrire mes formulaires avec le paramètre TYPE DE RECORDSET à
Feuille rép.dyn.(MAJ globale)
Au lieu de :
Feuille de réponse dynamique
Blocage à l'entrée d'1 formulaire...
Exécution de votre requête systeme :
http://pastebin.com/gsS3L4ku
Le protocol ne peut pas aller au delà de la v7
J'ai donc exécuté ma requête qui passe en mode verrouillé...
Voici mle résultat...
http://pastebin.com/R5BykGUB
Mon fichier de connexion DSN :
-----------------------------------
[ODBC]
DRIVER=PostgreSQL Unicode
Uid=xxxxx
PORT=5432
DATABASE=xxxxx
SERVER=192.168.0.120
XaOpt=1
LowerCaseIdentifier=0
UseServerSidePrepare=0
ByteaAsLongVarBinary=0
BI=0
TrueIsMinus1=1
DisallowPremature=0
UpdatableCursors=0
LFConversion=1
ExtraSysTablePrefixes=dd_
CancelAsFreeStmt=0
Parse=0
BoolsAsChar=0
UnknownsAsLongVarchar=0
TextAsLongVarchar=1
UseDeclareFetch=0
Ksqo=1
Optimizer=1
CommLog=0
Debug=0
MaxLongVarcharSize=8190
MaxVarcharSize=255
UnknownSizes=0
Socket=4096
Fetch=1024
ConnSettings=
ShowSystemTables=0
RowVersioning=0
ShowOidColumn=0
FakeOidIndex=0
Protocol=7.4-1
ReadOnly=0
SSLmode=disable
Merci de votre réponse. 1 première pierre enfin...
Je crois à fond que PostgreSQL est l'alternative dont nous avons besoin, pour ce projet et bien d'autres que nous avons en cours de réalisation...
Mon programme fonctionne d'abord dans 1 environnement Windows 2003 serveur.
Nous allons migrer sous peu, sur 1 nouveau serveur de type Windows v2008
PostgreSQL fonctionne sous Ubuntu 12.04 LTS 64 bits
La version de PostgreSQL est la v9.1 en 32 bits
La version du connecteur ODBC :
PostgreSQL UNICODE 9.01.02.00 PSQLODBC35W.DLL 20/08/2012
Le résultat de votre requête :
http://pastebin.com/aMc0FqnU
Merci de votre concours
Ai-je positionné ma demande au bon endroit ODBC, car il n'y pas de rubriques concernant spécifiquement ACCESS ?
J'ai choisi ODBC parce que je me dis que je dois rencontrer 1 problème lié à l'attachement de mes tables à mon programme...
Complément :
Des requêtes de ce type, simples, qui fonctionnaient même avec MySQL, se retrouvernt en lecture seule à présent...
----------------------------------------------------------------------------------------------------------------------------------
SELECT DISTINCT ComptaBolero_Mvts.nummvt, ComptaBolero_Mvts.codeanalbudg, ComptaBolero_Mvts.codejournal, ComptaBolero_Mvts.dateecriture, ComptaBolero_Mvts.libelle, ComptaBolero_Mvts.datetransfert, ComptaBolero_Mvts.ecritureattente, dossiers.ndos, dossiers.dossier
FROM (ComptaBolero_Mvts INNER JOIN rq_EcrComptable_MVTS ON ComptaBolero_Mvts.nummvt = rq_EcrComptable_MVTS.ecr_nummvt) INNER JOIN dossiers ON ComptaBolero_Mvts.codeanalbudg = dossiers.ndos
WHERE (((ComptaBolero_Mvts.codeanalbudg) Like "*") AND ((ComptaBolero_Mvts.datetransfert) Is Null))
ORDER BY ComptaBolero_Mvts.nummvt DESC;
---------------------------------------------------------
Il s'agit d'1 requête que j'appelle ensuite pour compléter les champs :
ComptaBolero_Mvts.datetransfert et ComptaBolero_Mvts.ecritureattente
Tout est verrouillé désormais...
Mon problème viendrait il des paramètres d'attachement de la table en question ?
1 base de données du type de celle de PostgreSQL permet de prendre 1 bonne dimension, sans être prisonnier d'1 solution TOUT Microsoft... Avec SQL Server, ce type d'anomalie ne se produit pas...
Le verrouillage de ma requête ne se faisait pas non plus avec MySQL...
Bonjour,
J'utilise 1 grosse application développée depuis des années sous ACCESS (DAO).
J'ai migré 1 partie de ma base de données sous PostgreSQL...
Au fur et à mesure de l'utilisation de mon programme et peut-être de l'adaptation de quelques structures de champs, ma base s'est peu à peu bloquée :
- Verrouillage de requêtes en lecture seule
- Enregistrements dans des tables verrouillées par des réservations (inexistantes) de la part d'autres utilisateurs...
Actuellement, mon application est à 2 doigts de s'écrouler du fait des verrous que je rencontre...
Je me demande donc si ma base est correctement déclarée lors e l'attachement de mes tables via ma connexion ODBC, ou elle le serait de manière incomplète avec ACCESS...
Sinon, à quel stade puis-je intervenir pour débloquer ces lignes, et faire en sorte que des requêtes, qui fonctionnaient parfaitement avec MySQL ou SQL Serveur, fonctionnent normalement avec PostgreSQL...
J'ai besoin d'1 éclairage rapidement...
Je souhaite m'appuyer sur PostgreSQL à l'avenir, qui est rapide et dont tout le monde semble enchanté...
Merci par avance
Pages : 1
