none
Migration 2002-XP vers 2003-Vista : Erreur 3441 Séparateur du champ identique au sép. déc. ou délim de texte. RRS feed

  • Question

  • Base de données initialement développée sous ACCESS 2002 – sans problème (Windows XP).

    Convertie ou pas sous ACCESS 2003, exécutée sous ACCESS 2003 (11.8321.8329) SP3 sous VISTA

     

    A l’exécution de la commande VBA

    « DoCmd.TransferText acExportDelim, , "QExtraction_Données", FichierExtractionLettre, True, "" »

     ou à l'aide de la Macro de transfert texte délimité correspondant, sans spécification d’extraction enregistrée, avec la spécification d’extraction par défaut de ACCESS 2003, la commande se plante sur le message suivant :

     

    « 3441 Le séparateur du champ de spécification du fichier texte est identique au séparateur décimal ou au délimiteur de texte. »

     

    Je n'ai pas eu echo de ce pb nul part. C'est étonnant. Le pb est un peut bloquant lorsque le fichier à extraire provient d'une requete compliquée.  Quelqu'un a t-il une idée? Merci.
    PMichard
    • Modifié ArgyronetModerator mardi 25 janvier 2011 11:07 Titre plus significatif par rapport à la demande
    mardi 18 janvier 2011 14:59

Toutes les réponses

  • Bonjour,

    La première chose à vérifier est que votre séparateur de champ ne rentre pas en conflit avec les séparateur de décimales du fichier texte.
    En théorie, le séparateur de champ est un par défaut dans bien des cas un point-virgule mais il est probable que sur le poste sur lequel vous travaillez, ce soit une virgule ce qui rentre en conflit avec le contenu du fichier.

    La seconde est de vérifier le contenu des champs DecimalPoint et FieldSeparator dans la base 2003 depuis la table MSysIMEXSpecs.


    Argy
    mardi 25 janvier 2011 11:04
    Modérateur
  • Merci pour l'info. Effectivement il y a des choses pas claires dans MSysIMEXSpecs

     

    Patrick


    PMichard
    mardi 25 janvier 2011 11:19
  • Dans ce cas, si la correspondance ne satisfait pas, il est préférable de regénérer les specs d'import en écrasant tout bonnement "QExtraction_Données"


    Argy
    mardi 25 janvier 2011 11:48
    Modérateur
  • Bonjour,

    Encore une foi merci pour votre intérêt.
    "QExtraction_Données" est la requête sous-jacente à l'export. Dans ACCESS 2000, je n'avais pas défini une spécification d'export pour cette fonction précise.

    Après une série de tests sur la base convertie 2002-2003 exécutée sous ACCESS 2003 11.8321.8329 SP3, je constate:
    - cette version n'exécute plus correctement l'extraction des données en .txt avec délimiteur si une spécification d'exportation n'a pas été créée au préalable. Dans la version précédente d'ACCESS 2000, cette possibilité fonctionnait même si absence de spécification d'export, les caractères séparateurs, point décimal, et autres étaient correctement récupérés dans les paramètres par défaut system.
    - cela oblige à la création d'une spécification explicite d'exportation. A ma connaissance, la seule possibilité est de passer par l'assistant d'exportation via la requête sous-jacente à l'export et d'enregistrer la spécification dans MSysIMEXSpecs (non modifiable directement!). Ors lorsque je veux enregistrer cette spécificcation, il refuse pour deux raisons:
        dans la requête sous jacente j'ai une table dupiquée en alias. Et cela il n'aime pas. Le nom des données relative à la table alias est trop long.
        dans cette requête j'ai des conditions "where" et "ou", ce qu'il n'aime pas non plus.

    - j'ai finalement modifier le nom de la table alias, enlevé provisoirement les conditions where et ou et j'ai réussi à créer la spécification d'export correctement! Et maintenant cela fonctionne!


    N'y a-t-il pas plus simple?


    PMichard
    jeudi 27 janvier 2011 09:13
  • Effectivement ; 2000 était ma base de référence pendant de nombreuse années ;o)

    En fait, il y a toujours plus simple...
    De manière général, ce que je ferais (et fais d'ailleurs dans mes projets) à votre place serait de créer une table depuis votre requête par le biais de la condition :
     - Si la table n'existe pas alors SELECT INTO... et éventuellement IN si la BDD est scindée
     - Sinon DELETE * FROM... puis INSERT INTO...
     - Et enfin votre TransferText...

    De là, du fait que votre table ne possède que les enregsitrements à exporter, vous n'avez plus de contraintes (WHERE...) telles que celles que vous évoquez...

    Les paramètres d'export défini dans MSysIMEXSpecs est effectivement une petite contrainte ; pour ma part, c'est un plus vraiment idéal, notamment pour le CharSet.


    Argy
    jeudi 27 janvier 2011 10:24
    Modérateur
  • merci et bonne journée.
    PMichard
    jeudi 27 janvier 2011 10:32