existe-t-il un outil permettant de comparer 2 fichiers mdb de façon
"globale" ?
Les fichiers contiennent, a priori, le même nombre de tables mais ces
tables peuvent différer en nombre de champs et en nombre
d'enregistrements et je ne trouve pas de programme qui me donne juste
ces infos. Et dans Access je trouve pas non plus.
Ouhla vu la taille des bases en question c'est un coup à avoir quel ques millions d'octets de différences.
Au fait ça serait une bonne idée de fractionner entre frontal et b ase dorsale ... Histoire de pouvoir d'un côté comparer les structures et traitements, de l'autre les données. Enfin les données c'est pour rigoler.
Pour rigoler ? Il n'y a pas de traitement, formulaires ou autres dans ces bases. Tout se fait par l'intermédiaire d'une application maison.
Ah, c'est juste les données qu'on veut comparer, alors ... Ah oui alors là il n'y a pas à tortiller, il faut ouvrir un jeu d'enregistrements de chaque côté, avancer les deux ensemble, et compa rer champ par champ ... Enfin sauf pour vérifier si les bases sont une sauvegarde l'une de l'autre, mais dans le cas général ...
J'imagine qu'il sera sain de commencer par vérifier les structures des jeux d'enregistrements (nombre de champs et leurs types), comme ça si les structures sont identiques, on peut, pour chaque enregistrement, faire une boucle sur les champs, ça va plus vite que les traiter un par un.
Alors après, comme pour comparer des fichiers texte, il y a des règle s à établir, pour savoir si on veut pouvoir détecter un enregistrement inséré, combien d'enregistrements on va voir plus loin pour retrouver la trace de ce qu'il y avait ... Il y a quand même de quoi s'amuser.
Frd a écrit, le 29/04/2013 09:18 :
Le 25/04/2013 23:58, Gloops a écrit :
Frd a écrit, le 23/04/2013 09:32 :
Ouhla vu la taille des bases en question c'est un coup à avoir quel ques
millions d'octets de différences.
Au fait ça serait une bonne idée de fractionner entre frontal et b ase
dorsale ... Histoire de pouvoir d'un côté comparer les structures et
traitements, de l'autre les données. Enfin les données c'est pour rigoler.
Pour rigoler ?
Il n'y a pas de traitement, formulaires ou autres dans ces bases.
Tout se fait par l'intermédiaire d'une application maison.
Ah, c'est juste les données qu'on veut comparer, alors ...
Ah oui alors là il n'y a pas à tortiller, il faut ouvrir un jeu
d'enregistrements de chaque côté, avancer les deux ensemble, et compa rer
champ par champ ...
Enfin sauf pour vérifier si les bases sont une sauvegarde l'une de
l'autre, mais dans le cas général ...
J'imagine qu'il sera sain de commencer par vérifier les structures des
jeux d'enregistrements (nombre de champs et leurs types), comme ça si
les structures sont identiques, on peut, pour chaque enregistrement,
faire une boucle sur les champs, ça va plus vite que les traiter un par un.
Alors après, comme pour comparer des fichiers texte, il y a des règle s à
établir, pour savoir si on veut pouvoir détecter un enregistrement
inséré, combien d'enregistrements on va voir plus loin pour retrouver la
trace de ce qu'il y avait ...
Il y a quand même de quoi s'amuser.
Ouhla vu la taille des bases en question c'est un coup à avoir quel ques millions d'octets de différences.
Au fait ça serait une bonne idée de fractionner entre frontal et b ase dorsale ... Histoire de pouvoir d'un côté comparer les structures et traitements, de l'autre les données. Enfin les données c'est pour rigoler.
Pour rigoler ? Il n'y a pas de traitement, formulaires ou autres dans ces bases. Tout se fait par l'intermédiaire d'une application maison.
Ah, c'est juste les données qu'on veut comparer, alors ... Ah oui alors là il n'y a pas à tortiller, il faut ouvrir un jeu d'enregistrements de chaque côté, avancer les deux ensemble, et compa rer champ par champ ... Enfin sauf pour vérifier si les bases sont une sauvegarde l'une de l'autre, mais dans le cas général ...
J'imagine qu'il sera sain de commencer par vérifier les structures des jeux d'enregistrements (nombre de champs et leurs types), comme ça si les structures sont identiques, on peut, pour chaque enregistrement, faire une boucle sur les champs, ça va plus vite que les traiter un par un.
Alors après, comme pour comparer des fichiers texte, il y a des règle s à établir, pour savoir si on veut pouvoir détecter un enregistrement inséré, combien d'enregistrements on va voir plus loin pour retrouver la trace de ce qu'il y avait ... Il y a quand même de quoi s'amuser.
Gloops
Frd a écrit, le 29/04/2013 09:11 :
Le 25/04/2013 23:56, Gloops a écrit :
Frd a écrit, le 23/04/2013 09:32 :
J'ai bien trouvé une application "CompareDB" mais elle se plante de suite...
Tiens, ça me rappelle vaguement quelque chose ... Raconte un peu pour voir ?
Oh y a pas grand chose à dire. Tu choisis les 2 bases à comparer, tu lances la comparaison, ça dit "runtime error invalid column value" et ça sort.
Hum, effectivement ... Il me semblait avoir déjà vu le nom quelque part, mais je n'en sais p as assez pour pouvoir aider face à ... tant de détails.
--
Frd a écrit, le 29/04/2013 09:11 :
Le 25/04/2013 23:56, Gloops a écrit :
Frd a écrit, le 23/04/2013 09:32 :
J'ai bien trouvé une application "CompareDB" mais elle se plante de suite...
Tiens, ça me rappelle vaguement quelque chose ...
Raconte un peu pour voir ?
Oh y a pas grand chose à dire.
Tu choisis les 2 bases à comparer, tu lances la comparaison, ça dit
"runtime error invalid column value" et ça sort.
Hum, effectivement ...
Il me semblait avoir déjà vu le nom quelque part, mais je n'en sais p as
assez pour pouvoir aider face à ... tant de détails.
