Base ACCESS 2010 fractionnée et liaison UNC

Malheureusement, je ne pourrai pas faire grand-chose aujourd'hui car il faut que j'avoue à la face du monde un honteux, lourd et terrible secret :





























































J'ai un métier...

;-)

Je te propose quelque chose aujourd'hui, dans la matinée...

Bon, il y a trois choses à faire :

1 - Positionner la valeur de Liaison dans TblLiaisonDorsale à faux, car sinon la valeur est 'NULL' (il suffit de décocher la case dans la table)
2 - Modifier la procédure MAJ, pour lui dire que si on a fait la mise à jour des liens il convient de mettre à jour le champ liaison de la table TblLiaisonDorsale
3 - Créer la procédure à mettre dans l'ouverture du formulaire principal.

1 - Tu devrais y arriver
2 - Ajouter une déclaration de variable en début de procédure (après tous les DIM existants) et mettre

Dim StrSql As String

Ajouter ensuite dans le code après la ligne "Set Db = Nothing"

        StrSql = "UPDATE TblLiaisonDorsale SET Liaison = -1;"  
        DoCmd.SetWarnings False  
        DoCmd.RunSQL (StrSql)  
        DoCmd.SetWarnings True

3 - Créer un code évènement "sur ouverture" du formulaire principal et mettre ce code :

If DLookup("Liaison", "TblLiaisonDorsale") = 0 Then  
    MAJ  
End If  

Ca devrait marcher...

Oublie les commentaires ci-dessus.
Je reviens vers toi dès que possible.

Me revoilà.
Mes connaissances sur les champs OUI/NON laissaient plutôt à désirer : restons à OUI = -1 et NON = 0 et oublions ce commentaire du 26 (comme quoi les connaissances ne sont jamais définitivement acquises...).

Ceci dit, la procédure de démarrage fonctionne bien (il suffisait de créer réellement un enregistrement dans la table tblLiaisonDorsale en cliquant 2 fois de suite dans le champ OUI/NON...).

Encore une fois merci!

Cependant, 2 choses me gênent :
- pour que la procédure de MAJ des liaisons soit lancée à l'ouverture, il faut avoir placé manuellement le booléen à 0 avant la fermeture de la base ....
Ne serait-il pas mieux de faire en sorte que la procédure de MAJ se lance à l'ouverture dès lors que la liaison avec la dorsale ne s'effectue pas? (mais peut-être serait-ce un peu trop abusé de ma part...)
- le 2ème point est plus gênant : il semble lorsque la procédure de MAJ est lancée la 1ère fois, qu'une liste des tables de la dorsale soit créée quelque part, et serve ensuite de référence pour les MAJ des liaisons à venir. Il en résulte à priori, qu'il n'est pas possible de faire évoluer ultérieurement l'applicatif en créant d'autres tables dans la dorsale. J'ai fait 2 tests :
- création d'une nouvelle table dans la dorsale : la procédure de MAJ l'ignore)
- Modification d'un nom de table de la dorsale : la procédure de MAJ se plante. Access ne trouve plus le nom initial de la table (ce qui tend à prouver qu'une liste est bien constituée à la 1ère MAJ, mais je ne sais pas où...)

Ceci dit, la procédure de démarrage fonctionne bien (il suffisait de créer réellement un enregistrement dans la table tblLiaisonDorsale en cliquant 2 fois de suite dans le champ OUI/NON...).
C'est que j'ai indiqué dans mon point 1.

Ne serait-il pas mieux de faire en sorte que la procédure de MAJ se lance à l'ouverture dès lors que la liaison avec la dorsale ne s'effectue pas? (mais peut-être serait-ce un peu trop abusé de ma part...)
Ce n'est pas ce qui est demandé au départ, il était question d'une 'première visite', c'est-à-dire que l'on vient d'installer la frontale sur un poste, mais il ne voit pas la dorsale. C'est le cas de la première installation.
Ca peut sûrement se solutionner (je ne l'ai cependant jamais fait).

- le 2ème point est plus gênant : il semble lorsque la procédure de MAJ est lancée la 1ère fois, qu'une liste des tables de la dorsale soit créée quelque part, et serve ensuite de référence pour les MAJ des liaisons à venir. Il en résulte à priori, qu'il n'est pas possible de faire évoluer ultérieurement l'applicatif en créant d'autres tables dans la dorsale. J'ai fait 2 tests :
- création d'une nouvelle table dans la dorsale : la procédure de MAJ l'ignore)
- Modification d'un nom de table de la dorsale : la procédure de MAJ se plante. Access ne trouve plus le nom initial de la table (ce qui tend à prouver qu'une liste est bien constituée à la 1ère MAJ, mais je ne sais pas où...)
Comportement tout à fait normal...
- Lorsque tu as créé ta frontale tu es allée dire que les tables étaient liées à la dorsale.
Si tu créés une table dans la dorsale, comment veux-tu que la frontale soit au courant si tu ne créés pas la table liée correspondante dans la frontale ?
- modification d'un nom de table dans la dorsale qui plante le code VBA : tu auras le même problème si tu fais ta gestion de tables liées avec le menu (sans code VBA).

Si tu es dans un cadre de développement classique, alors tu ne dois distribuer que des frontales (fichiers .mde ou .accde), c'est donc à toi de gérer le changement de modèle de données...

En fait, il suffit de comprendre qu'access n'est pas en mesure d'analyser ce genre de modifications humaines...

Mes connaissances sur les champs OUI/NON laissaient plutôt à désirer : restons à OUI = -1 et NON = 0
Dans tous les basic que j'ai utilisés (et dans d'autres langages), cette convention a toujours existé...

Je viens de regarder (ça pourra aussi me servir un jour, qui sait).

Il suffit de créer une macro 'autoexec' qui exécutera une fonction de test des attaches.

1 - Créer dans un module une fonction de vérification de l'ouverture possible des tables, si pas possible appeler la procédure de mise à jour des liens.

Function Ctrl_Liens() 
Dim Db As Database 
Dim Tb As TableDef 
Dim Rs As DAO.Recordset 
Set Db = CurrentDb 
' Test des attachements 
' On exclut les tables système 
' ainsi que les tables non attachées 
On Error GoTo Fin: 
For Each Tb In Db.TableDefs 
    If Left(Tb.Name, 4) <> "MSys" And Tb.Connect <> "" Then 
        Set Rs = Db.OpenRecordset(Tb.Name) 
        Rs.Close 
    End If 
Next 
Fin: 
If Err.Number = 3024 Then 
    MAJ() 
Else 
    MsgBox "Erreur " & Err.Number & " : " & Err.Description 
End If 
End Function 

2 - Créer une macro (qui sera enregistrée sous le nom obligatoire de 'autoexec'). Elle comprendra l'action 'exécutercode' et prendra comme paramètre 'Ctrl_Liens ()', soit le nom de la fonction créée auparavant...

Ca devrait marcher tout seul...

J'ai juste oublié d'ôter les parenthèses...:-(

Effectivement, la gestion des erreurs est mal faite (je me suis dépêché), remplace par ça :

On Error GoTo Erreur:   
For Each Tb In Db.TableDefs   
    If Left(Tb.Name, 4) <> "MSys" And Tb.Connect <> "" Then   
        Set Rs = Db.OpenRecordset(Tb.Name)   
        Rs.Close   
    End If   
Next  
GoTo Fin:   
Erreur:   
If Err.Number = 3024 Then   
    MAJ 
Else   
    MsgBox "Erreur " & Err.Number & " : " & Err.Description   
End If   
Fin:  
End Function 

Tu fais bien comme tu veux, c'est TON appli ;-)

rien d'extraordinaire...

C'est la frontale que tu as mise en accde ?

Tu l'ouvres sur le poste où tu l'as créée ou c'est ailleurs ?
Je pense à un problème de références : un poste où l'installation d'access n'est pas correcte ou une bizarrerie comme ça...

Ben là, je suis sec...

J'ai fait différents tests (en vain...) et il y en a un qui me donne des résultats surprenant, à savoir :
dans ma base accdb, j'ai renommé mon module "CtlLiaisonsOuvertureBase" et lui ait donné le même nom que le code qu'il contient [Ctrl_liens() mais sans saisir les ()], et dans ce cas j'ai le même plantage avec les mêmes messages d'anomalie...
Si ça peut t'éclairer......

Je pense que le code disparait quand tu fais un accde, mais je ne sais pas pourquoi...
Peut-être une option cachée ?

J'ai fait testé l'appli (avant transformation en accde) sur un autre poste : à ma grande surprise la macro autoexec plante sur ExecuterCode Action Ctrl_Liens (erreur 2001)..... donc idem que chez moi mais uniquement sur ma base en accde et avec un code erreur n°3270 cette fois-ci...

La macro plante sur quelle ligne ?

et si tu ne mets pas cette macro, en appelant la procédure ailleurs ?

Si on met la procédure ailleurs le contrôle des liaisons ne se fera plus à l'ouverture de la base.....
Peu importe, ce que je voudrais savoir, c'est si le code est appelable...

Cette fois-ci, le problème est résolu! Je passe les détails de tout ce que j'ai pu faire pour en venir à bout....
Au final, j'ai recréé une base vierge dans laquelle j'ai importé tous les objets de mon frontal et j'ai compilé le code.
Maintenant, l'accde qui résulte de cette nouvelle base fonctionne parfaitement (même sur un autre poste que le mien).

Super :-)