Discussion :

[besly]

Bonjour,

J'ai une mdb qui interprète après une importation de données venant d'un fichier dbase, ce fichier dbf comporte des champs dont un a un caractère accentué "ù", ce qui à pour effet de donner un message d'erreur à l'issue de l'importation de ce fichier sur deux des dizaines de stations qui utilisent cette mdb. En effet, sur ces stations le caractère "ù" dans l'un des noms de champ de la table est différent des autres stations qui utilisent la mdb et me donne ainsi un message d'erreur comme quoi il ne trouve pas le champ dans la table...

: Ma question : A l'importation, Access s'appui t-il sur une page de code caractères et peut-elle être différente d'une station à l'autre ? Et si oui, comment peut-on la changer sur ces deux stations ?

Merci pour votre aide…


PS : Les stations tournent sous W2k et XP pro avec MSAccess 2000 & 2003.

[argyronet]

Bonjour

Les champ de DBase sont limités:
1/ à 11 ou 13 caractères (je ne sais plus)
2/ Non séparés par des caractères comme l'espace entre autres
3/ Non accentués
4/ En majuscule
5/ Avec un Underscore (_) comme séparateur

Ton ù ne respecte pas une de ces conditions
A toi de faire en sorte que ça le soit.

Argy

[besly]

Code :

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

1
2
3
4
5
6
7
8
9
Les champ de DBase sont limités: 
1/ à 11 ou 13 caractères (je ne sais plus) 
2/ Non séparés par des caractères comme l'espace entre autres 
3/ Non accentués 
4/ En majuscule 
5/ Avec un Underscore (_) comme séparateur 
 
Ton ù ne respecte pas une de ces conditions 
A toi de faire en sorte que ça le soit.

Je ne peux pas intervenir sur la structure du fichier dbf qui provient d'une autre application, je ne fais que l'importer. Il se trouve que sur toutes les stations deux indiquent autres choses que "Ú" dans l'un des noms de champs de la table Access ainsi nouvellement créée après l'importation.
Il n'y a pas un paramètrage avant l'import d'un code page unicode, ascii ?

[argyronet]

Celui qui a développé la base n'a pas respecté (malheureusement comme beaucoup de développeurs qui s'en fiche, du moment que ça marche) les conventions de nommage.
Une base de données ne DOIT JAMAIS POSSEDER D'ESPACE pour les nom de champs, ni de caractère autre que les 26 lettres de l'alphabet greffé éventuellement d'un _. C'est une norme et c'est bien triste de travailler comme ça.

Sur quelles stations cela fonctionne et sur quelles stations cela ne fonctionne pas ? (Quelle version d'Access avec quel OS et SP Windows ?)

Argy

[besly]

Sur quelles stations cela fonctionne et sur quelles stations cela ne fonctionne pas ? (Quelle version d'Access avec quel OS et SP Windows ?)

Les stations tournent sous W2k avec MSAccess 2000 et XP pro avec MSAccess 2003. Sur toutes les stations aussi bien w2k que xp pro quand je fais importer le fichier DBase, les noms de champs qui avait un "é" dans leur nom sont convertis en "Ú", jusque là rien d'anormal(for me ). Le pb est que sur les deux stations en questions(une en w2k et l'autre en xp pro) après l'import de ce fichier dbf dans access, les noms des champs qui comportaient un "é" sont convertis dans un autre caractère genre un symbole dos "╔" se qui modifie la structure de la table et fait planter mon interface access quand j'interroge cette table. Y-a-t-il un code page par défaut sur lequel s'appuit access au moment de l'import et si oui comment fait-on pour le changer ?

Merci pour ton aide...

[argyronet]

Donc, ça ne vient pas de l'OS mais plutôt du ou des composants d'importation ayant une mauvaise version. Par exemple, le fichier Msxbde40.dll pour Access 2000 est le pilote ISAM servant à importer les fichiers DBase entre autres.
Il est probable, je précise probable que ce soit cela.
Déjà compare les versions des DLL qui sont les pilotes ISAM d'un poste où ça fonctionne (aussi bien en XP qu'en W2K) et ceux où ça plante puis envisage alors de mettre à jour les versions.

Argy

[besly]

Ok, je vais voir la version des dll et les comparer au boulot dès que je rentre de congé.

Bonnes fêtes et je te tiens au courant...

[guigui76esi]

Salut,

Voici peut etre une solution "plus bourrin" tu ouvre le fichier dbf avec excel, tu localise le ù et tu le transforme en ce que tu veux, tu ferme et tu importe

C'est pas tres "jolie" mais ca devrait marcher...

[besly]

Voici peut etre une solution "plus bourrin" tu ouvre le fichier dbf avec excel, tu localise le ù et tu le transforme en ce que tu veux, tu ferme et tu importe

Non, ce n’est pas possible, le fichier dbf est recréé systématiquement par un autre programme et je ne peux pas demander aux utilisateurs distants de faire cette manip.

[guigui76esi]

pas par l'utilsateur mais via le code.

dans le style,

Code :

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
18
19
20
 
Dim xl As Excel.Application
Dim wbk As Excel.Workbook
Set xl = New Excel.Application
xl.Visible = False
Dim chemin As String
 
chemin = "C:\...\xxx.dbf"
 
With xl
    Set wbk = .Workbooks.Open(chemin)
    With wbk.Sheets("TC1")
  .range("A1").Value = "aze1"
    End With
End With
wbk.SaveAs ("c:\ici.dbf")
wbk.Close
xl.Quit
Set wbk = Nothing
Set xl = Nothing

[besly]

pas par l'utilsateur mais via le code.

Merci guigui76esi, mais j'aimerais savoir pourquoi sur ces deux stations ça "merdouille" et sur quel paramètre ou fichier il faut agir pour palier au pb au cas ou il se reproduirait, ton idée est intéressante mais pas suffisante dans mon cas.

Je suis pratiquement sûr que se n'est pas grande chose!!!