Discussion :

[sevyc64]

Salut à tous.

Code VB6, base ACCESS 97

Pour des besoins de tests de performance sur les bases, je suis en train de faire un petit utilitaire qui doit éclater une base access 97 existante avec plus d'une centaine de tables, en autant de base avec chacune une des tables de la base source.
J'utilise le code suivant :

Code vb6 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
    Set bdsrc = DBEngine.Workspaces(0).OpenDatabase(cheminbase & "mabasesource.mdb")
    For Each tb In bdsrc.TableDefs
        If (tb.Attributes = 0) And (tb.Name <> "") Then
            ReDim Preserve tbnames(UBound(tbnames) + 1)
            tbnames(UBound(tbnames)) = tb.Name
        End If
    Next
 
    Dim acApp As Access.Application
    Set acApp = New Access.Application
    acApp.OpenCurrentDatabase cheminbase & "mabasesource.mdb"
    For i = LBound(tbnames) + 1 To UBound(tbnames)
        Set bddest = DBEngine.CreateDatabase(cheminbase & tbnames(i) & ".mdb", dbLangGeneral, dbVersion30)
 
        bddest.Close
        Call acApp.DoCmd.TransferDatabase(acExport, "Microsoft Access", cheminbase & tbnames(i) & ".mdb", actable, tbnames(i), tbnames(i))
    Next

Lorsque je tente d'ouvrir les bases ainsi générées, je me ramasse 2 messages d'erreur

Impossible de lire les enregistrements; pas d'autorisation de lecture sur 'MSysObjects'

puis

Impossible de lire les enregistrements; pas d'autorisation de lecture sur 'MSysACEs'

Sur la base source, j'ai un fichier system.mdw. je précise que je ne maitrise pas l'utilisation de ce fichier.
J'imagine que, sur les bases créées, je dois renseigner, ou copier depuis la base source, quelque chose par rapport à ce fichier mdw ?

[marot_r]

Bonjour.

Les tables MSys* sont des tables systems et autant que je sache on ne peut pas changer les droits dessus.

Sur la base source, j'ai un fichier system.mdw. je précise que je ne maitrise pas l'utilisation de ce fichier.
J'imagine que, sur les bases créées, je dois renseigner, ou copier depuis la base source, quelque chose par rapport à ce fichier mdw ?

Sauf si tu as defini un fichier de securite (.mdw) particulier pour ta base, Access utilise le fichier System.mdw.
Donc ca devrait marcher tout seul.

Tu peux forcer Access a utiliser un fichier specifique via la ligne de commande.
Tu as cela ici :
https://access-programmers.co.uk/for...d.php?t=176511
Ces parmis les derniers de la liste.

Cree-toi un .bat avec quelque chose du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
call "c:\TonCheminVersAccess97\MSACCESS.EXE" "X:\TonCheminVersTaBD.mdb" /wrkgrp "y:\ToncehminVersMdw\System.mdw"
pause

Le pause te permet de voir d'eventuels message d'erreur.

Fait aussi un scan de la machine qui fait fonctionner ta BD initiale a la recherche de fichier .mdw.
Tu en as peut-etre plusieurs et ce n'est peut-etre pas celui qu'on crois qui est utiliser.

As-tu essayer de faire un export a la main d'une de tes tables et ensuite ouvrir la BD resultat ?

A+

[marot_r]

Et tu ouvres bien ta BD Access 97 avec Access 97, n'est-ce pas ?

A+

[sevyc64]

Fait aussi un scan de la machine qui fait fonctionner ta BD initiale a la recherche de fichier .mdw.
Tu en as peut-etre plusieurs et ce n'est peut-etre pas celui qu'on crois qui est utiliser.

Bonne idée, on est pas à l'abri de surprise

As-tu essayer de faire un export a la main d'une de tes tables et ensuite ouvrir la BD resultat ?
A+

Pas de cette base. Mais de sa soeur jumelle, utilisée par l'applicatif, oui. Elle n'avait que 18 tables, donc celles là, je les avais exportées manuellement avec Access et je n'ai pas eu ce problème

Mais là, plus d'une centaine de tables, j'ai pas envie de le faire à la main. Et en plus j'en ai une troisième à faire ou il y en a le double encore.

Et tu ouvres bien ta BD Access 97 avec Access 97, n'est-ce pas ?

Oui, j'ouvre manuellement la base avec Access pour vérifier quelle a bien été exportée.
Je n'ai pas encore essayer de l'ouvrir directement avec l'applicatif car il faut d'abord que je l'adapte à ces nouvelles bases.

[marot_r]

Bonjour.

Pas de cette base. Mais de sa soeur jumelle, utilisée par l'applicatif, oui. Elle n'avait que 18 tables, donc celles là, je les avais exportées manuellement avec Access et je n'ai pas eu ce problème

Prend le temps avec juste une table, cette BD est peut-etre endomagee sans que cela se voit.

Tu did que tu as utilise VB6.
Peut-etre peux-tu faire du code VBA (le langage de Access) pour refaire ton export.
D'Access a Access ca se passe generalement bien.

100 tables dans une seule BD, c'est beaucoup. Il y a peut-etre un probleme d'architecture.
Cela n'explique pas ton probleme mais ca vaudrait sans doute le coup d'investiguer et d'envisager une reachitecturation.

Et attention, il me semble que 97 n'est plus supporte par les nouvelles version d'Access.
Donc tu ppourrais te retrouver dans un cul de sac si tu tardes trop a migrer ton appli vers une version plus recente.

A+

[sevyc64]

L'applicatif qui utilise ces bases est écrit en VB6. Il fonctionne depuis une 20ène d'années, régulièrement mis à jour pour corriger les bugs, etc...

On rencontre depuis quelques mois, des petits soucis chez certains clients, allant jusqu'à la corruption des bases, et on arrive pas à les identifier pour les corriger. L'éclatement des bases est une piste pour peut-être arriver à identifier le problème.
Le cas échéant, si cela résout le problème sans que l'on est d'autres pistes, il faudra donc faire l'éclatement des bases existantes directement chez les clients, et ce de manière sure et automatique lors d'une mise à jour.

Quant à la migration, elle est déjà enclenchée depuis plus de 2ans, mais au rythme actuel on estime à environ 3-4 ans pour pouvoir migrer tous les clients de ce logiciel.

[marot_r]

Bonjour.

L'applicatif qui utilise ces bases est écrit en VB6.

Oui mais ton "explosion" c'est ponctuel donc peut-etre la faire par VBA resoudrait le probleme.
Une fois tes BD correctes, tu peux reprendre VB6 pour continuer la vie de ton produit.

A+

[sevyc64]

Bon, petit retour sur l'aventure.

Après que l'équipe de test ait fait son travail, il s'avère que, avec les bases éclatées, elle n'arrive pas à faire péter les bases. Je reste persuader que le problème n'est pas résolu, mais juste masqué désormais.

Bref, à défaut d'autres pistes, c'est donc la solution à mettre en place chez les clients. Il va donc falloir que je bétonne mon code car il va falloir éclater les bases des clients, de manière sure et en automatique lors de la mise à jour. Pas question d'intervenir manuellement, ils sont trop nombreux.

J'ai du changer mon code, et créer manuellement les bases et tables car je me suis rendu compte que le DoCmd ne fonctionnait pas sur tous les postes. A priori, si Access n'est pas installé sur le poste, mon code ne fonctionne pas. Et ça sera le cas chez une majorité des clients.

Juste pour ma culture personnelle, il faut obligatoirement Access sur le poste, ou faudrait-il prévoir la distribution de certains composants avec le setup de mise à jour pour que ça fonctionne sans avoir à installer Access ?
Il me faut Access parce que dans mon code je passe par un Access.Application, mais j'ai pas trouvé comment accéder autrement à DoCmd

[marot_r]

Il y a le runtime Access qui est un faux Access juste capable d'exécuter une appli. Le problème va être de trouver un runtime Access 97.

Une idée pour contourner le problème : fournir à ton client une série de bases éclatées vides et transférer ses données dans tes tables vides puis après utiliser ta collection. Comme cela tu n'as pas à faire l'éclatement chez le client.

[sevyc64]

C'est effectivement ce que je fais actuellement. Mais ce n'est tout de même pas sans risque d'autant plus que par manque de temps, je ne prévois rien pour faire le cheminement inverse. Donc si ça plante au moment de la mise à jour, il y aura une sauvegarde, mais si ça plante plusieurs jours après, il n'y aura plus rien.

[marot_r]

Bonjour.

mais si ça plante plusieurs jours après, il n'y aura plus rien.

Pas grand chose a faire contre cela sinon inviter tes clients a faire des sauvegardes quotidiennes pendant une "certaine" periode de temps (ex : 1 mois) et considerer que passe ce delais c'est correct.

Tu peux aussi envisager de faire toi-meme une copie automatiquement des donnees a la sortie de l'application.
Ca depend un peu du volume de tes donnees mais avec les disques actuels, ce n'est pas forcement un probleme de garder 30j de copies.

A+