Discussion :

[cleataz]

Bonjour,

Impossible d'exporter une table access en format csv
Les nouvelles commandes obligent obligatoirement à 4 formats et je ne trouve pas le format .csv avec séparateur de virgule ou point-virgule...

Si quelqu'un a une solution je suis preneuse !!!

Merci d'avance pour votre aide !

Clea

[curt]

Bonjour cleataz,

à priori en version 2010 il faut passer par VBA.
Fais une recherche dans l'aide avec TransferText

ça devrait correspondre à ça :

Code :

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

1
2
DoCmd.TransferText acExportDelim, "Standard Output", _
    "External Report", "C:\Txtfiles\MyText.csv"

(trouvé sur un autre site ! )

Curt

[Invité]

Bonjour

Ne coche pas l'option : Exporter les données avec la mise en forme et la mise en page.

Là tu pourras ensuite choisir ton séparateur.

Lorsque tu arrives à la dernière étape, modifier l'extension, transforme le .txt en .csv

Cela est également valable pour Access 2007.


Philippe

[kennely]

Bonjour,

J'ai posté une questions sur http://www.developpez.net/forums/d10...ccess/pb-isam/, mais n'ai pas encore reçu de réponse.
Ne reste-t-il aucun développeur sur ce forum, au mois d'Août ?

Sous ACCESS 2010, version 14.0.7615.1000, sous Windows 7 Entreprise SP1, la commande

Code :

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

DoCmd.TransferText acExportDelim, , tbname, ficname, True

génère le message d'erreur suivant :
"Le séparateur du champ de spécification du fichier texte est identique au séparateur décimal ou au délimiteur de texte."

Le séparateur décimal dans les paramètres régionaux de Windows est le ","
Je ne peux le modifier,ni créer de fichier de spécification d'export (nombre de tables, et structures des tables à exporter, susceptibles d'être modifiées)

Comment définir le symbole ";" comme délimiteur par défaut, pour les exports au format csv, dans ACCESS ?

Merci pour votre aide

[fsmrel]

Bonsoir kennely,

J'ai essayé un export manuel, en spécifiant séparateur ";" et texte entre "", cela fonctionne.
Si je crée un fichier de spécification d'export et que je l'utilise avec une table, cela fonctionne.
J'ai 77 tables à exporter, je ne vais pas créer 77 fichiers de spécification, d'autant plus que la structure des tables est susceptible d'être modifiée.]

J’arrive peut-être un peu tard, mais bon... Je ne suis spécialiste ni d’ACCESS ni de VBA, donc il faudra que vous vérifiiez ce que j’ai codé. En tout cas, j’ai procédé ainsi (avec ACCESS 2013) :

1) Remplacement de

DoCmd.TransferText acExportDelim, "", tbname, ficname, True

Par

DoCmd.TransferText acExportHTML, , tbName, ficName, True

2) Je me suis coltiné une fonction VBA qui transforme en fichier csv chaque fichier html généré. Le code VBA se trouve dans le module Module1 du fichier .ACCDB que je joins.

Suite à la commande TransferText, je suis obligé de fermer les fichiers html, car ce crétin d’ACCESS les laisse manifestement ouverts, ce qui fait que je suis obligé de fermer aussi votre fichier #1 (je ne sais pas si on peut faire autrement)...


A vous de voir, et de bricoler le code VBA...


Bon courage.

[fsmrel]

Bonsoir kennely,


Une variante, qui crée directement les fichiers CSV (c’est donc nettement plus rapide). Le fichier .mdb correspondant est ici.

[fsmrel]

Bonsoir kennely,


J’ai observé que la fonction TransferText ne se comporte pas toujours comme on le voudrait : elle n’évacue pas le symbole "€" pour le type Currency, elle ne remplace pas la virgule décimale par un point décimal dans le cas des données de type décimal, qu’elle considère comme étant du texte (en fait type non JET). Si une donnée de type date ne comporte que l’heure, la fonction complète avec la date du 30 décembre 1899... En outre, elle ne fait pas la différence entre Null et absence d’information...

Au cas où cela vous intéresserait encore, je joins une version plus complète que celle que j’avais fournie le 22 août dernier, laquelle comportait un bug : oubli de traiter les colonnes marquées nulles (on y retrouvait donc des scories...)

En ce qui concerne les dates, je remplace le format JJ/MM/AAAA par le format AAAA-MM-JJ, mais au besoin, on peut s’abstenir. Pour les données numériques avec virgule décimale, je remplace celle-ci par un point décimal. Étant donné que je teste ensuite les résultats avec MySQL, à la demande de celui-ci, je remplace la marque nulle par la valeur "\N" (j’ignore ce que demande Oracle, car je ne l’utilise pas). Accessoirement, j’ai remplacé le type de fichier csv par txt, mais on remet facilement les choses en place. Je n’ai pas encadré les données de type Texte (y-compris dans l’en-tête) par des guillemets, mais au besoin je le fais.

Dernière version : csv_export_tabledefs2.zip

[kennely]

Merci beaucoup fsmrel.
Je teste cela de suite

[kennely]

Bonjour fsmrel,

J'ai testé ton module hier en fin d'après-midi, et ai du l'interrompre, car c'est très long.
J'ai un lien ODBC entre ACCESS et Oracle, et doit récupérer le contenu de 70 tables.

J'ai calculé la somme de toutes les lignes, de toutes les tables.
Cela représente 21 523 340 lignes.

Le temps d'exécution est long, très long.

La solution donnée ici me semble meilleure, mais elle ne fonctionne pas

[fsmrel]

Bonjour kennely


Qu’est-ce qui ne marche pas ? Vous avez un message d’erreur ? C’est le résultat qui ne convient pas ? Dans vos tables, vous avez des données contenant des séparateurs ?

[kennely]

C'est le temps d'exécution qui est trop long !
Tout fonctionne parfaitement.
Aucun message d'erreur.
Que des données date, texte ou réel, sans séparateur

[Invité]

Salut

Etant donné le volume cela ne m'étonne pas que ce soit long, ce qui est sûr c'est que cela ne sera pas instantané, et donc combien de temps cela dur ?

Philippe

[fsmrel]

Bonjour kennely,

C'est le temps d'exécution qui est trop long !
Tout fonctionne parfaitement.

Bien. Il faudra donc procéder en plusieurs temps. Pour voir, je suggère :

1) De lister les noms des tables à exporter, avec leur volumétrie (en nombre de lignes), dans l’ordre des moins volumineuses aux plus volumineuses. Pour cela, vous pouvez utiliser la macro Cardinalités (cf. le .mdb csv_export_tabledef_3.zip) qui permet de créer le fichier ad-hoc Cardinalites.txt.

2) Sur la base du contenu du fichier Cardinalites.txt, de saucissonner le travail de création des fichiers CSV, de manière à ne pas tout faire en une fois.

Merci de communiquer le contenu du fichier Cardinalites.txt (au besoin par message privé).

[Clairant]

Bonjour cleataz,
Moi j'ai exploré la démarche du modérateur Philippe, mais ça marche très bien. En fait, j'ai exporté plutôt la table vers excel (n'importe quel formal xlsx, xls,..) et ensuite après exportation tu enregistres le fichier exporté sous .csv avec séparateur de virgule et ça marche. Bien que cela ne soit pas trop professionnel mais c'est bien une alternative.
Bon courage.

[kennely69]

Bonjour,

Désolé pour le temps de réponse, mais je ne suis pas notifié des nouveaux posts.

J'ai interrompu le code au bout de 5H d'exécution.
Le délai est trop long, j'ai besoin d'exporter le contenu de ces tables toutes les nuits après 5H30, et les données doivent être disponibles à 9H, au plus tard.

J'ai finalement opté pour une autre solution.
Je disposais d'une base de données SQL Server.
J'ai créé mes 77 tables, puis via un projet Visual Studio, je mets à jour mes tables locales, via un lien ODBC ente SQL Server et Oracle, puis j'exporte le contenu des tables locales, au format CSV.

Je fait le traitement en deux étapes, car j'ai ensuite un autre projet Visual Studio qui lance des requêtes SQL, pour un autre traitement.

Je ne comprends pas pourquoi la solution avec Access fonctionnait avec Access 2000, sous Windows XP, et plus avec Access 2010' sous Windows 7.

Merci à tous pour votre aide.