Discussion :

[wizlord]

Je suis nouveau sur ce forum, mais je développe avec Access 2000 depuis 6 ans déjà.

Habituellement, je parviens à régler les bugs en consultant ce forum ou d'autre ressources sur Internet, mais cette fois-ci, je ne trouve rien qui ressemble à mon problème.

Voici ma situation:

J'ai 3 bases de données Access 2000 et je dois créer une seule nouvelle base de données Access 2000 qui contient l'ensemble de toutes les tables des 3 BD.

Pour y parvenir, je pourrais bien sûr importer les tables de toutes les BD dans une nouvelle BD Access 2000, mais je veux permettre à l'utilisateur (mon client) de choisir les 3 BD à combiner et éventuellement lui permettre d 'en choisir 4, 5...

Jusqu'ici tout va bien.

Je me suis dit que si l'utilisateur choisit 2 BD dont une ou plusieurs des tables comporte le même nom, il y aurait un problème. C'est pourquoi je fait une simple petite manipulation sur les tables avant d'en faire la copie: je renomme chaque table en y ajoutant un suffixe différent pour chaque BD. De cette façon, je suis presque sûr que les tables n'auront pas le même nom.

J'ai donc conçu un programme Access 2000 qui utilise DAO 3.6. Une des tables retient le chemin d'accès vers les BD à combiner, leur mot de passes et leurs suffixe.

Lorsque l'utilisateur appuie sur le bouton "Combiner", le code s'exécute, produisant une erreur.

Je vais expliquer sous peu l'erreur en question, mais laissez-moi vous parlez du code qui s'exécute.

Le code est simple. Si quelqu'un le demande, je vais le publier ici, mais je ne crois pas que ce soit pertinent puisque le code en tant que tel est impecable. Pour l'instant, je vais seulement inclure un pseudo-code afin d'expliquer le problème.

//Début du pseudo-code

Création d'une nouvelle BD Access 2000
Ouverture de la table qui contient l'information sur les BD à combiner
Loop à travers toute les BD à combiner
Connection à la BD i en utilisant le bon mot de passe
Loop à travers toutes les tables (les objets TableDefs) de la BD i
Si la table n'est pas une table système ou une table cachée Alors
Création d'un nouvel objet TableDef nommé TD
//L'objet TD a comme structure source la Table j
//L'objet TD a le même nom que la table j plus le suffixe
Loop à travers tous les champs de la table j
Ajout du champ k à la colletcion Fields de l'objet TD
FinLoop
Ajout de l'objet TD à la collection TableDefs de la nouvelle BD
FinSi
FinLoop
Exéction d'un requête SQL SELECT INTO
//la requête SELECT INTO envoie les données dans la nouvelle table
FinLoop

//Fin du pseudo-code

Ce code marche dans plusieurs cas. Dailleurs, je croyais que le programme fonctionnait jusqu'à ce que je l'installe chez mon client.

Voici mon problème:

Lorsque j'essaye de combiner les 3 BD en question, le programme plante sur la toute première table avec l'erreur 3190 "Too many fields defined". Trop de champs définis? Je n'en ai que 12 dans cette table!

En effet, le programme plante sur une table qui n'a que 12 champs. Comment Access, VBA ou DAO fait pour croire que j'ai dépassé la limite de 255 champs? Je fais pratiquement une copie conforme des tables! (mis à part le fait que je les renomme)

Quelqu'un a une idée?

Merci d'avoir eu la patience de lire mon message.

wizlord

[Muhad'hib]

Salut et bienvenu sur le forum,

Sans rapport avec une résolution du problème en lui même, mais bon :

Et-il nécessaire de créer la structure de la table, puis de coller les données dedans ? Il existe des requètes création de table qui font tout ça en une seule fois.

Par exemple regarde ce post


A+

[milia]

Bonjour,

désolé je n'ai pas eu le courage de tout lire (d'autant qu'il manque les balise code qui facilite la lectuer), mais ce n'est pas parce que tu as 12 champs qu'il y a forcément la place encore, si tes 12 champs sont très volumineux et bien ça passe pas

Bon courage.

[VBBBA]

je serais curieux de voir ton code....

[wizlord]

Salut et bienvenu sur le forum,

Sans rapport avec une résolution du problème en lui même, mais bon :

Et-il nécessaire de créer la structure de la table, puis de coller les données dedans ? Il existe des requètes création de table qui font tout ça en une seule fois.

Par exemple regarde ce post


A+

Non, il n'est pas nécessaire pour moi de créer la structure de la table, puis de coller les données dedans. C'est simplement le moyen que j'ai trouvé pour renommer toutes les tables.

Aussi, afin de simplifier les choses, j'ai omis de vous dire que je renomme aussi tous les champs pour une autre raison dont je n'expliquerai pas les détails. Cela n'a aucune incidence sur le problème en cours puisque quand je met les lignes de codes liées à cette fonctionnalité en commentaires, le même problème survient.

En fait, je suis presque certain qu'une requête SQL ne peut pas faire ça (renommer toutes les tables et tous les champs). Est-ce que je me trompe?

Merci

wizlord

[wizlord]

Bonjour,

désolé je n'ai pas eu le courage de tout lire (d'autant qu'il manque les balise code qui facilite la lectuer), mais ce n'est pas parce que tu as 12 champs qu'il y a forcément la place encore, si tes 12 champs sont très volumineux et bien ça passe pas

Bon courage.

C'est moi qui est désolé pour l'indentation horrible de mon pseudo-code. Lorsque j'ai posté mon message, j'avais pourtant tous bien indenté, mais il semble que le forum efface pour moi les espaces en début de ligne.

Comme je vous l'ai dit, je suis nouveau sur ce forum.

Vous pouvez copier-coller le code dans un éditeur texte et indenté tous les Loop et le Si pour mieux voir le code.

En réponse à ton message, voici la description de mes 12 champs:

- 10 champs numériques entier long
- 2 champs texte 20 car max

Comme tu peux voir, mon problème ne se situe pas à ce niveau puisque la taille de mes champs est loin de dépasser la limite d'Access.

Merci quand même!

wizlord

[wizlord]

je serais curieux de voir ton code....

Voilà! J'ai attaché un fichier zip qui contient le code fautif. Amusez-vous!

[giloo(94)]

que se passe-til si tu importe manuellement la table concernée?
si ca marche pourquoi ne pas faire pareil dans ton code...mis a part le changement du nom des colonnes...que tu peut faire dans un 2° temps
....

[wizlord]

que se passe-til si tu importe manuellement la table concernée?
si ca marche pourquoi ne pas faire pareil dans ton code...mis a part le changement du nom des colonnes...que tu peut faire dans un 2° temps
....

Oui, une importation manuelle des tables fonctionne.

Faire pareil dans mon code? Tu veux dire utiliser quelque chose comme doMenuItem pour exécuter le menu "Importer des tables"? Et ensuite renommer les champs?

Ce n'est pas fou du tout. Je vais essayé ça et je vous en reparle.

Merci à tous! Je ne m'attendais pas à des réponses si rapides.

wizlord

[pgz]

Faire pareil dans mon code? Tu veux dire utiliser quelque chose comme doMenuItem pour exécuter le menu "Importer des tables"? Et ensuite renommer les champs?

Plutôt que d'utiliser une commande d'interface, regarde

Code :

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

DoCmd.TransferDatabase acImport, ...

qui te permettra en plus de renommer en même temps ta table.

Bon courage,

PGZ

[wizlord]

Merci pour vos suggestions...J'ai l'impression que j'approche de la solution!

Mon nouveau problème est le suivant:

Peut-on utiliser la commande Docmd.TransferDatabase pour transférer des tables à partir d'une BD protégée par un mot de passe vers une BD aussi protégée par un mot de passe?

Merci

[LaBelette]

Peut-on utiliser la commande Docmd.TransferDatabase pour transférer des tables à partir d'une BD protégée par un mot de passe vers une BD aussi protégée par un mot de passe?

Je crois que l'utilisateur doit exister dans les trois BD, c'est à dire dans les trois fichiers de sécurité (MDW), avec le même PID et mot de passe.
Il doit aussi avoir les droits nécessaires dans chacune des BD, bien entendu.

Bien sur, si tu utilises le même MDW pour les trois BD, alors pas de problème!

[wizlord]

Je crois que l'utilisateur doit exister dans les trois BD, c'est à dire dans les trois fichiers de sécurité (MDW), avec le même PID et mot de passe.
Il doit aussi avoir les droits nécessaires dans chacune des BD, bien entendu.

Bien sur, si tu utilises le même MDW pour les trois BD, alors pas de problème!

Je n'utilise pas les fichiers de sécurité de Access. Je parlais de bases de données protégées par mot de passes (menu Outils->Sécurité->Définir le mot de passe de la base de données)

Merci quand même

[wizlord]

Plutôt que d'utiliser une commande d'interface, regarde

Code :

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

DoCmd.TransferDatabase acImport, ...

qui te permettra en plus de renommer en même temps ta table.

Bon courage,

PGZ

Merci! Ça marche!

Pour ceux que ça intéresse. Voilà comment j'ai fait:

-j'ai déclaré 2 instances d'objets Access.Application oAcc1 et oAcc2.

-j'ouvre la base de données destination avec oAcc1.OpenCurrentDatabase(...). (Avant j'utilisait Application.DBEngine.OpenDatabase(...))

-pour chaque BD source que je veux combiner, j'ouvre la base de données source avec oAcc2.OpenCurrentDatabase(...).

-ensuite, quand j'utilise oAcc2.TransferDatabase avec acExport comme premier paramètre, Access ne me demande pas le mot de passe.

Voila!

Merci!

wizlord

[philippe2811]

J'ai aussi ce genre de problème en important des données de exell. J'avais trop de champs sur ma table et impossible de les modifier.
Voilà ce que j'ai fait.
J'ai enregistrer sous ma table en la renommant. J'ai supprimer celle qui me posait un problème. J'ai renommé la nouvelle avec le nom de celle que je venais de supprimer.
Et depuis, plus de problème pour ajouter des champs.

[wizlord]

J'ai aussi ce genre de problème en important des données de exell. J'avais trop de champs sur ma table et impossible de les modifier.
Voilà ce que j'ai fait.
J'ai enregistrer sous ma table en la renommant. J'ai supprimer celle qui me posait un problème. J'ai renommé la nouvelle avec le nom de celle que je venais de supprimer.
Et depuis, plus de problème pour ajouter des champs.

Merci pour la réponse, mais ce n'est pas le problème qui m'affecte présentement. J'avais essayé ce dont tu parle...j'avais déjà vu ce problème sur d'autres forum. Mais ça ne marche pas dans mon cas. De toute façon, j'ai contourné le problème et maintennt, ça marche!

[wizlord]

J'ai aussi ce genre de problème en important des données de exell. J'avais trop de champs sur ma table et impossible de les modifier.
Voilà ce que j'ai fait.
J'ai enregistrer sous ma table en la renommant. J'ai supprimer celle qui me posait un problème. J'ai renommé la nouvelle avec le nom de celle que je venais de supprimer.
Et depuis, plus de problème pour ajouter des champs.

Merci pour ta réponse, mais mon problème est un peu différent. J'avais lû cette solution un peu partout sur les forums: ré-enregistrer toutes les tables qui posent problème et j'avais essayé sans succès.

Je n'ai jamais trouvé la cause de mon problème 'Erreur 3190', mais j'ai réussi à le contourner en changeant mon approche.

Ce post a été noté comme 'Résolu' puisque j'ai réussi à atteindre mon but, mais si quelqu'un comprend pourquoi Access me disait que j'avais trop de champs, j'aimerais bien le savoir pour satisfaire ma curiosité.

Merci quand même!