Modifier une table liée en cours de lecture

Bonjour,

A l'ouverture mais aussi à la fermeture d'un formulaire de ma base frontale, je souhaite exécuter un SQL (UPDATE...) sur ma base dorsale.
je me confronte au message d'erreur d'exécution 3048 et l'impossibilité d'ouvrir plusieurs bases de données.
Mes tables liées semblent être en lecture seule et je n'arrive pas à contourner mon problème.

Un extrait de mon code :

Code:

---

1 2 3 4 5 6 7 8 9 10

Dim strChemin as string Dim DistantDB as DAO.Database Dim SQLcode as string   strChemin = CurrentProject.Path & "MaBaseDorsale.mdb" Set DistantDB = OpenDatabase(strChemin) SQLcode = "UPDATE ......" DistantDB.Execute SQLcode DistantDB.Close Set DistantDB = Nothing

---

Merci

Salut.

Pourquoi ouvres-tu la dorsale? Une table liée se comporte comme un table locale. Tu peux donc l'adresser directement sans devoir ouvrir la dorsale.

Merci pour la réponse

Aussi j'ai testé ce code pour modifier la table mais rien ne semble se mettre à jour...y a un truc qui doit m'échapper....

Code:

---

1 2 3 4 5 6 7 8

Dim DB as DAO.Database Dim SQLcode as string   Set DB = Currentdb SQLcode = "UPDATE ......" DB.Execute SQLcode DB.Close Set DB = Nothing

---

Il faudrait donner le code sql utilisé.

le code SQL:

Code:

---

"UPDATE INTERLOCUTEURS SET dateMAJ = dateMAJ2 WHERE N°INTERLOCUTEUR = " & Me.N°INTERLOCUTEUR & ";"

---

Ce code SQL a pour vocation depuis mon formulaire "INTERLOCUTEURS" de modifier un champs de ma table liée portant le même nom...

Si ton n°interlocuteur est une valeur string, tu dois l'encadrer entre des apostrophes.

Code:

---

UPDATE INTERLOCUTEURS SET dateMAJ = dateMAJ2 WHERE N°INTERLOCUTEUR = '" & Me.N°INTERLOCUTEUR & "';"

---

DateMAJ2 est un champ de la table Interlocuteurs ou bien cette date vient-elle d'ailleurs? Si elle vient d'ailleurs (variable ou date système), tu dois aussi l'intégrer dans la requête comme tu l'as fait pour le n°Interlocuteur.

Le N°interlocuteur est une valeur numérique...
et DateMAJ2 est bien un champs de ma table INTERLOCUTEURS
et pour être plus complet , il y a 2 codes sql que j'execute en réalité

Code:

---

1 2	SQLcodif1 = "UPDATE INTERLOCUTEURS SET dateMAJ = dateMAJ2 WHERE N°INTERLOCUTEUR = " & Me.N°INTERLOCUTEUR & ";" SQLcodif2 = "UPDATE INTERLOCUTEURS SET dateMAJ2 = Date() WHERE N°INTERLOCUTEUR = " & Me.N°INTERLOCUTEUR & ";"

---

Désolé pour toutes ces cachoteries!!!

Je ne vois pas ce qui pourrait poser problème.

As-tu bien actualisé le formulaire après l'exécution de code pour refléter les mises à jour?

Oui je l'ai bien actualisé...
petit problème, en fait l'évènement "sur ouverture" du formulaire s'était désactivé.
Mais en le réactivant et en utilisant le code précédent, j' ai toujours un message d'erreur d'exécution 3048...je suis insistant mais j'ai l'impression que le fait de vouloir faire des modifs sur la table interlocuteurs de la base dorsale depuis la base frontale pose des problèmes d'accès de lecture seule.
Merci pour ta disponibilité

Le fait que la table soit liée ne pose aucun problème. Je viens de le tester par acquit de conscience.

Lorsque tu as l'erreur, vérifie la chaîne SQL pour voir quelle commande sql est effectivement générée. C'est probablement là que tu pourras voir l'erreur.

Assure-toi aussi que DateMaj2 est bien une date valide. Si elle vaut NULL, assure-toi que DateMaj peut recevoir cette valeur.

Citation:

---

Envoyé par béodéo

[...]je suis insistant mais j'ai l'impression que le fait de vouloir faire des modifs sur la table interlocuteurs de la base dorsale depuis la base frontale pose des problèmes d'accès de lecture seule.[...]

---

Il faut évidemment que la dorsale ne soit pas ouverte en lecture seule à l'ouverture de la frontale.

Bonjour
Après quelques vérifs concernant le code SQL...aucun problème de ce coté là étant donné qu'avant d'être fractionnée ma base et ce code SQL a toujours parfaitement fonctionné...idem pour la mise à jour du champs DateMAJ2.
Depuis le fractionnement je n'arrive pas à contourner le message d'erreur d'execution 3048 qui bloque à la ligne de code :

Code:

---

DB.Execute SQLcodif1

---

un indice peut être : au moment de l'execution du code SQL le .ldb de la base dorsale est ouvert...

Le LDB est ouvert dès lors que la base est utilisée, en direct ou via les tables liées. Donc, rien d'anormal à ce niveau-là.

Peux-tu utiliser

Code:

---

DoCmd.RunSQL SQLCode

---

à la place de

Code:

---

DB.Excecute SQLCode

---

et nous dire ce qui se passe?

bonsoir

j'ai encore un message d'erreur mais différent :

Erreur d'exécution '3000':
Erreur réservée (-1104) : aucun message n'est assigné à cette erreur.

Petite remarque :
j'ai le même message d'erreur quand mon formulaire est ouvert et que j'essaie d'ouvrir ma table avec le double clic :

Y a-t-il des accès concurrents sur ta table?

Citation:

---

Envoyé par béodéo

Petite remarque :
j'ai le même message d'erreur quand mon formulaire est ouvert et que j'essaie d'ouvrir ma table avec le double clic :

---

As-tu un enregistrement en modification dans la table et/ou le formulaire au moment de la tentative d'exécution de la requête SQL?

Histoire de circonscrire le problème, si tu rapatries cette table en local, as-tu toujours le problème?

avec la table en local : plus aucun problème...
dans mon formulaire j'ai des sous formulaires qui utilisent (via des requêtes) cette fameuse table : peuvent-ils faire office de "concurrents" ?

bonjour,

bien vérifier que :
- toutes les bases ouvertes avec opendatabase sont fermées avec close
(ne pas fermer si ouvert avec set db = currentdb)
- toutes les base instanciées (set db = currentdb ou set db = opendatabase(...)) sont libérées (set db = nothing)
- tous les recordset ouverts avec set rs = db.openrecordset sont fermés avec rs.close et libérés avec set rs = nothing)

parfois si ne libère pas explicitement avec set ... = nothing (et surtout si on ne ferme pas (avec close) ce qu'on a ouvert), il reste un objet ouvert et au bout d'un moment ça coince

sinon, éviter les noms de tables ou champs avec des caractères spéciaux (le ° de N°INTERLOCUTEUR), on a parfois des problèmes incompréhensibles avec ces caractères (surtout les anciennes versions d'access).

bon courage, pas facile à pister ce genre d'erreur

Salut Arkham,

Content de voir ta bestiole ;)

Ce qui est étrange, c'est que cela se passe avec une table liée et pas avec la même table rapatriée en local. Je pense pourtant que le comportement des objets mal fermés est le même en local qu'en lié, non?

Citation:

---

Envoyé par Pierre Fauconnier

Ce qui est étrange, c'est que cela se passe avec une table liée et pas avec la même table rapatriée en local. Je pense pourtant que le comportement des objets mal fermés est le même en local qu'en lié, non?

---

Faut voir le code...
Si en local c'est du Set db = CurrentDb au lieu de Set db = OpenDatabase(...) alors ça change tout.

Je suppose que le test liée/locale a été effectué sans modification du code.

Cela dit, il utilise set db = currentdb, donc il n'ouvre pas à nouveau sa base, non?

Cela étant, sur une table liée, il n'a même pas besoin d'utiliser set db =.

Il peut créer la chaîne de requête et l'utiliser directement avec docmd.runsql qui va travailler sur CurrentDB par défaut.

Ta remarque est donc judicieuse, car pour travailler en sql sur les tables liées, tout comme sur les locales d'ailleurs, il peut supprimer les objets DB. Cela supprimerait les connexions intempestives via set db =, quelle que soit la façon d'attribuer une base à l'objet DB.