Version imprimable
Bonjour, :roll:
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 !!!:cry::cry::cry:
Merci d'avance pour votre aide !
Clea
Bonjour cleataz,
à priori en version 2010 il faut passer par VBA.
Fais une recherche dans l'aide avec TransferText
ça devrait correspondre à ça :(trouvé sur un autre site ! :ccool:)Code:
2
Curt
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
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
génère le message d'erreur suivant :Code:DoCmd.TransferText acExportDelim, , tbname, ficname, True
"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
Bonsoir kennely,
Citation:
Envoyé par kennely
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.
Bonsoir kennely,
Une variante, qui crée directement les fichiers CSV (c’est donc nettement plus rapide). Le fichier .mdb correspondant est ici.
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
Merci beaucoup fsmrel.
Je teste cela de suite
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 :(
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 ?
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
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
Bonjour kennely,
Bien. Il faudra donc procéder en plusieurs temps. Pour voir, je suggère :Citation:
Envoyé par kennely
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é).
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.
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.