Changer le format d'Export d'un fichier txt suite à un programme VBA

Version imprimable

Voir 40 message(s) de cette discussion en une page

Bonjour à tous,
Ce message fait suite à une problématique précédente qui avait été brillamment résolue par PAIDGE à l'époque.
Le programme consistait à identifier des utilisateurs qui répondaient favorablement à plusieurs conditions avec une relation complexe (l'utilisateur doit avoir cette condition ET cette condition OU cette condition).
Le programme fonctionne parfaitement. Il délivre un fichier txt sous la forme:
---
"USER1";"Condition1:Valeur de condition1;Condition2:Val2;C3:Val3"
"USER2";"C2:Val2;C3:Val3"
------
Le programme est le suivant :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 Public Function BProcessEligibles(pUNAME As String) As Variant ' Ceci est la fonction qui renvoit la liste des zones éligibles pour un client ' La valeur retournée est de cette forme : "SUD:01;NORD:03" Dim strSQL As String, strBProcess As String Dim rstBProcessProbables As DAO.Recordset ' On récupère les zones susceptibles d'être éligibles strSQL = "SELECT DISTINCT BP, Transaction " & _ "FROM AGR_1251_Y_MERGE_finale_star_TMP_2 INNER JOIN FUNCTOBJ_GRC " & _ "ON (AGR_1251_Y_MERGE_finale_star_TMP_2.LOW = FUNCTOBJ_GRC.Value) " & _ "AND (AGR_1251_Y_MERGE_finale_star_TMP_2.FIELD = FUNCTOBJ_GRC.Field) " & _ "AND (AGR_1251_Y_MERGE_finale_star_TMP_2.OBJECT = FUNCTOBJ_GRC.Object) " & _ "WHERE UNAME='" & pUNAME & "';" Set rstBProcessProbables = CurrentDb.OpenRecordset(strSQL) ' Pour chacune de ces zones, While Not rstBProcessProbables.EOF ' On réunit les champs Secteur et éligibilité séparés par ":" strBProcess = rstBProcessProbables(0) & ":" & rstBProcessProbables(1) ' On vérifie si le client est éligible. Si c'est le cas, on concatène les zones séparées par des point-virgules If transaction_elue(pUNAME, strBProcess) Then BProcessEligibles = BProcessEligibles & ";" & strBProcess End If rstBProcessProbables.MoveNext Wend ' On retire le premier point-virgule If Len(BProcessEligibles) <> 0 Then BProcessEligibles = Right(BProcessEligibles, Len(BProcessEligibles) - 1) End Function
----

Néanmoins, j'ai besoin de faire un lourd travaille de refonte de ce fichier car je dois l'incorporer dans une nouvelle table. Le travail devient vite infernal lorsque que je dépasse la 50aine d'utilisateurs :calim2:. Idéalement, j'aurai besoin que le fichier d'export txt ressemble à ceci:

"USER1";"Condition1:Valeur de condition1"
"USER1";"Condition2:Val2"
"USER1";"C3:Val3"
"USER2";"C2:Val2"
"USER2";"C3:Val3"

---

Pensez-vous qu'il est possible d'influencer le code du programme pour avoir cette restitution ?
Merci pour votre aide et votre contribution.

dagada75

bonjour,

Je verrais une solution dans ce genre :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Public Function BProcessEligibles(pUNAME As String) As Variant
    ' Ceci est la fonction qui renvoit la liste des zones éligibles pour un client
    ' La valeur retournée est de cette forme : "SUD:01;NORD:03"
    Dim strSQL As String, strBProcess As String
    Dim rstBProcessProbables As DAO.Recordset
 
    ' On récupère les zones susceptibles d'être éligibles
    strSQL = "SELECT DISTINCT UNAME,BP, Transaction " & _
             "FROM AGR_1251_Y_MERGE_finale_star_TMP_2 INNER JOIN FUNCTOBJ_GRC " & _
             "ON (AGR_1251_Y_MERGE_finale_star_TMP_2.LOW = FUNCTOBJ_GRC.Value) " & _
                "AND (AGR_1251_Y_MERGE_finale_star_TMP_2.FIELD = FUNCTOBJ_GRC.Field) " & _
                "AND (AGR_1251_Y_MERGE_finale_star_TMP_2.OBJECT = FUNCTOBJ_GRC.Object); "
    Set rstBProcessProbables = CurrentDb.OpenRecordset(strSQL)
 
    ' Pour chacune de ces zones,
    While Not rstBProcessProbables.EOF
        If transaction_elue(pUNAME, strBProcess) Then
 ' On concatene  le uname , ";" champs Secteur ,":" et éligibilité
        strBProcess = rstBProcessProbables(0) & ";" & rstBProcessProbables(1)& ":" & rstBProcessProbables(1) _
		& ch(13) & chr(10) 'on rajoute un CRLF pour changer de ligne
        ' On vérifie si le client est éligible. Si c'est le cas, on concatène les zones séparées par des point-virgules
        End If
        rstBProcessProbables.MoveNext
    Wend
 
    BProcessEligibles = strBProcess
End Function

Il faut après mettre le retour de la fonction dans un fichier

Sinon, tu peut adapter et transformer la fonction en procédure, et directement dans un fichier texte

03/10/2013, 17h33
dagada75

Merci pour ton soutien dumas.blr.

j'ai répliqué ton code. Malheureusement une erreur survient ave le message suivant "Erreur de compilation: Sub ou Function non définie".
Le correcteur pointe automatiquement ton rajout sur la valeur "rstBProcessProbables (1) _"

Est-ce lié au fait que je n'ai pas indiqué l'intégralité du programme ?

Dagada75

Oui, je n'ai pas testé le source que j'ai écrit:mouarf:
il y a une erreur dna s le code source : il fallait écrire chr(13) au lieu de ch(13)
Voici le code "corrigé" (mais toujours pas testé :mouarf::mouarf::mouarf:)

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Public Function BProcessEligibles(pUNAME As String) As Variant
    ' Ceci est la fonction qui renvoit la liste des zones éligibles pour un client
    ' La valeur retournée est de cette forme : "SUD:01;NORD:03"
    Dim strSQL As String, strBProcess As String
    Dim rstBProcessProbables As DAO.Recordset
 
    ' On récupère les zones susceptibles d'être éligibles
    strSQL = "SELECT DISTINCT UNAME,BP, Transaction " & _
             "FROM AGR_1251_Y_MERGE_finale_star_TMP_2 INNER JOIN FUNCTOBJ_GRC " & _
             "ON (AGR_1251_Y_MERGE_finale_star_TMP_2.LOW = FUNCTOBJ_GRC.Value) " & _
                "AND (AGR_1251_Y_MERGE_finale_star_TMP_2.FIELD = FUNCTOBJ_GRC.Field) " & _
                "AND (AGR_1251_Y_MERGE_finale_star_TMP_2.OBJECT = FUNCTOBJ_GRC.Object); "
    Set rstBProcessProbables = CurrentDb.OpenRecordset(strSQL)
 strBProcess = ""
    ' Pour chacune de ces zones,
    While Not rstBProcessProbables.EOF
        If transaction_elue(pUNAME, strBProcess) Then
 ' On concatene  le uname , ";" champs Secteur ,":" et éligibilité
        strBProcess = strBProcess & rstBProcessProbables(0) & ";" & rstBProcessProbables(1) & ":" & rstBProcessProbables(2) _
		& chr(13) & chr(10) 'on rajoute un CRLF pour changer de ligne
        ' On vérifie si le client est éligible. Si c'est le cas, on concatène les zones séparées par des point-virgules
        End If
        rstBProcessProbables.MoveNext
    Wend
 
    BProcessEligibles = strBProcess
End Function

Mais il me semble plus pertinent d'écrire directement dans un fichier texte. tu n'aurais pas de problème de taille

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
Public sub BProcessEligibles
    ' Ceci est la fonction qui renvoit la liste des zones éligibles pour un client
    ' La valeur retournée est de cette forme : "SUD:01;NORD:03"
    Dim strSQL As String, strBProcess As String
    Dim rstBProcessProbables As DAO.Recordset
    Dim numfictexte as integer
 
    Numfictexte = freefile  ' Lit le numéro de fichier inutilisé.
' Crée le nom du fichier.
 
    Open <chemin complet du fichier texte en sortie> For Output As #Numfictexte
 
 
    ' On récupère les zones susceptibles d'être éligibles
    strSQL = "SELECT DISTINCT UNAME,BP, Transaction " & _
             "FROM AGR_1251_Y_MERGE_finale_star_TMP_2 INNER JOIN FUNCTOBJ_GRC " & _
             "ON (AGR_1251_Y_MERGE_finale_star_TMP_2.LOW = FUNCTOBJ_GRC.Value) " & _
                "AND (AGR_1251_Y_MERGE_finale_star_TMP_2.FIELD = FUNCTOBJ_GRC.Field) " & _
                "AND (AGR_1251_Y_MERGE_finale_star_TMP_2.OBJECT = FUNCTOBJ_GRC.Object); "
    Set rstBProcessProbables = CurrentDb.OpenRecordset(strSQL)
 
    ' Pour chacune de ces zones,
    While Not rstBProcessProbables.EOF
        If transaction_elue(pUNAME, strBProcess) Then
 ' On concatene  le uname , ";" champs Secteur ,":" et éligibilité
        strBProcess = rstBProcessProbables(0) & ";" & rstBProcessProbables(1) & ":" & rstBProcessProbables(2) _
		write #Numfictexte, strBProcess ' Écrit le texte
        ' On vérifie si le client est éligible. Si c'est le cas, on concatène les zones séparées par des point-virgules
        End If
        rstBProcessProbables.MoveNext
    Wend
 
    close #Numfictexte ' Ferme le fichier.
End sub

04/10/2013, 10h29
dagada75

1 pièce(s) jointe(s)

Merci dumas.blr !

J'ai appliqué tes corrections ... mais cela entraîne une réaction en chaîne sur le reste du programme :aie:

Je crois que le plus simple pour toi (j'aurai du le faire dès le début!) est de joindre un exemple concret avec une base access.

L'idée d'un export direct en fichier txt me tente bien en effet ( ta solution numéro 2).

Quelques instructions sur la base:
- il faut exécuter la requête "FINAL_results" pour obtenir le résultat escompté

Le reste tu connais.

ps: oui c'est assez long (5min.) car je contrôle beaucoup d'information

Merci encore si tu peux y jeter un petit coup d'oeil

David
04/10/2013, 15h12
dumas.blr

Bonjour David,

J'ai ouvert ta base. J'ai déjà constaté quelque chose

Citation:

oui c'est assez long (5min.) car je contrôle beaucoup d'information

Tu peux déjà réduire sensiblement les temps de traitement en mettant des index sur les champs de jointure.

Je regarde la suite quand j'aurai un peu de temps
04/10/2013, 17h47
dagada75

Merci bien !!:ccool:

En effet, ... le temps de traitement pour 100 utilisateurs ... pas moins de 8H !!
Mais ca a le mérite de marcher (Merci Paidge!) :ccool:
04/10/2013, 18h13
dagada75

"en mettant des index sur les champs de jointure"

..... comment ? :aie::aie::aie:

4 pièce(s) jointe(s)

Citation:

comment ?

Est-ce toi qui a constitué cette base ou t'a-t'elle été mise à disposition ?
L'extraction que tu as mise à disposition reprend-elle la structure de la base d'origine ?

prenons l'exemple dans ton code :
Code:

1 2 3 4 5 6 strSQL = "SELECT DISTINCT BP, Transaction " & _ "FROM AGR_1251_Y_MERGE_finale_star_TMP_2 INNER JOIN FUNCTOBJ_GRC " & _ "ON (AGR_1251_Y_MERGE_finale_star_TMP_2.LOW = FUNCTOBJ_GRC.Value) " & _ "AND (AGR_1251_Y_MERGE_finale_star_TMP_2.FIELD = FUNCTOBJ_GRC.Field) " & _ "AND (AGR_1251_Y_MERGE_finale_star_TMP_2.OBJECT = FUNCTOBJ_GRC.Object) " & _ "WHERE UNAME='" & pUNAME & "';"
les jointures se font entre les tables, sur les champs :
tables FROM AGR_1251_Y_MERGE_finale_star_TMP et FUNCTOBJ_GRC -> champs AGR_1251_Y_MERGE_finale_star_TMP_2.LOW et FUNCTOBJ_GRC.Value
+ champs AGR_1251_Y_MERGE_finale_star_TMP_2.FIELD et FUNCTOBJ_GRC.Field
+ AGR_1251_Y_MERGE_finale_star_TMP_2.OBJECT et FUNCTOBJ_GRC.Object

il faudra donc indexer :
sur la table AGR_1251_Y_MERGE_finale_star_TMP_2:
- les champs LOW, .FIELD et object
sur la table FUNCTOBJ_GRC :
les champs Value, Field et Object

etc.

Pour indexer tes colonnes :
- ouvre la table en mode création
-regarde pour chaque champ les index (cf. capture 1)
Pièce jointe 128173 tu constates qu'aucun index n'a été créé sur cette table
- pour chaque champ à indexer , dans la rubrique "indexé", choisi "Oui - Avec doublons" (cf. capture 2) Pièce jointe 128174 tu constates que l'index a été ajouté (cf. capture 3) Pièce jointe 128175
-Répète l'opération sur les autres champs, jusqu'à ce que tous les index soit créés (cf. capture 4)Pièce jointe 128176

06/10/2013, 16h30
dumas.blr

1 pièce(s) jointe(s)

Bonjour David,

Je n'avais pas vu au début que ta fonction était directement appelée dans la requete FINAL_results. Il était normal que cela ne fonctionne pas.
Pour rappel, une fonction doit retourner une valeur suite à un traitement.
J'ai donc mis mon code dans une procédure et mis tout cela dans un module indépendant. Comme les autres fonctions étaient en PRIVATE, je les ai aussi incluses dans le module, de manière à ce qu'elles soient appelée.
Je te joins le module, que tu n'aura plus qu'à intégrer dans ton projet VBA (commande fichier-importer un fichier) en choisissant le fichier .bas que tu trouveras ci-joint
Je te joins aussi le fichier de sortie que j'ai généré à partir de ton jeu d'essai. Tu pourras ainsi voir si c'est bien le résultat que tu attends.
Pièce jointe 128184
Pour info, j'ai rajouté des index, et le traitement à tourné en 1mn30

Tu pourras constater que je n'ai quasiment rien modifié par rapport au code initial. il fallait juste le mettre dans une procédure indépendante, que j'ai appelé "refonte".
07/10/2013, 21h56
dagada75

Bonsoir Dumas !

Je ne sais quoi te dire à part Mille Mercis.
Je vais jeter un coup d œil ASAP mais déjà je voulais te remercier pour le temps consacré et ton professionnalisme .. Très pédagogique ! Détaillé !
Je te tiens au courant.

David
08/10/2013, 11h04
dagada75

J'ai du loupé un truc :)
- j'ai indexé les tables
- j'ai importé ton module

Lorsque je lance la requête "FINAL_results", j'obtiens le même résultat qu'avant. :aie:
Je me doute bien que je dois changer qqchose dans la requête pour "pointer" vers ton module non ??

Merci,
David
08/10/2013, 12h50
dumas.blr
Citation:

J'ai du loupé un truc

effectivement, il y a quelque chose que tu n'as pas saisi:ccool::mouarf:

J'ai écrit une procédure qui ne peut pas être utilisé dans ta requête. Elle doit donc être exécuté de manière indépendante.

je pense qu'il te faut comprendre quelques différences fondamentales entre les requêtes, les fonctions et les procédures.
Quand tu auras un peu de temps, regarde ce tuto qui t'expliquera bien a différence entre les procédures et les fonctions. Ma démarche n'a rien de condescendante:oops:, mais il me semble nécessaire, pour bien avancer, de ne pas mettre la charrue avant les boeufs !

Pour faire court,dans ton cas perso,je vais essayer de t'expliquer les principales fonctionnalités.
- Une requête sert principalement à accéder au données (consultation avec les clause SELECT), mais aussi pour les modifier (clauses UPDATE, INSERT, DELETE), plus rarement pour adiministrer les tables (clause CREATE, DROP, ALTER ...). La syntaxe la plus utilisée pour accéder est le SQL (que tu connais un peu).
- Les procédures (clauses sub en VBA) permettent d'exécuter des actions dans un programme
- Les fonctions (clauses FUNCTION en VBA) retournent des information en fonctions de paramètres d'entrée. EN principe, elles ne servent uniquement qu'à cela, d'où mon commentaire précédent
Citation:

Pour rappel, une fonction doit retourner une valeur suite à un traitement.

. Elles sont en général appelées dans un programmes.

Dans le cas de ta base, une fonctionnalité, peu connue mais très puissante, d'Access a été utilisée : celle de rajouter des "built-in functions" au SQL.

Le SQL standard est dotées de fonctions de bases, mais certaines fonctions sont liées à la base de donnée (tel le DECODE en Oracle). Enfin, certaines bases de données permettent la création de fonctions personnalisées, qui peuvent être utilisées dans le SQL.

Dans le cas d'Access, il est possible d'utiliser directement dans le SQL des fonctions crées en VBA.
C'est le cas dans ta base de donnée, où le développeur a élaboré une fonction pour retourner des informations mise en forme en fonction de critères complexes.
Dans ton cas, il est préférable de ne pas appeler les fonctions directement dans une requête SQL, mais plustôt d'appeler directement la procédure en exécutant la procédure du module.
La commande qu'il fallait faire était juste à exécuter ... refonte:D:ccool:

Sauf que tu va te dire :? comment exécuter refonte ? :?
Eh bien, rien de plus simple ! :mouarf:

Dans le VBA, tu as 2 façons de le faire :
1. Soit tu te positionne sur la procédure du module, et tu exécute la macro (F5 - ou menu exécution-exécuter la macro)
2. soit tu ouvres la fenêtre d'exécution (Ctrl+G ou menu affichage - fenêtre exécution) et tu tape simplement refonte
08/10/2013, 16h23
dagada75

c'est génial DUMAS !

J'ai fait tourner la macro et ca fonctionne !!

Je vais relire tes tutos avec intérêt car effectivement je m'emmêle les pinceaux ... tu m'as bien "diagnostiqué" ... je me débrouille en ce qui concerne les SQL et les requêtes.
Mais le VBA reste une grande inconnue.
Quand je vois les possibilités qu'il offre, je ne te raconte pas la frustration ... mais au delà d'une connaissance technique; c'est une vraie nouvelle façon de raisonner qu'il faut maîtriser.

Mais les participants sur ce forum sont géniaux. Je reste ébahi par votre (vous tous!) haut niveaux et le fait que vous fassiez toujours cela bénévolement. Je n'ai jamais eu un défaut de réponse sur chacune de mes questions. TOP ! :ccool:

Encore merci.

david
13/11/2013, 16h27
dagada75

Bonjour,
Je me permets de réouvrir temporairement ce fil de discussion.
En effet, je pensais que l'extraction d'un fichier txt permettrait de résoudre mon soucis.
Je me rends compte que ce fichier peut-être altéré par une modification ultérieure.
En fait, j'aimerai savoir s'il est possible d'influencer le code VBA du programme en maintenant la FORME du fichier txt mais en intégrant le résultat du programme exécuté directement dans une table ACCESS existante, et non plus en générant un fichier txt.
Le travail qui a été accompli est déjà très bon. C'est un vraiment un "nice to have" que je demande ici afin de sécuriser mes donnnées.

Dagada75

Bonjour à tous,

En suivant les conseils de dumas.blr, j'ai aménagé le code selon:
Code:

1 2 3 4 5 6 7 8 If transaction_elue(pUNAME, strBProcess) Then ' On concatene le uname , ";" champs Business Process ,";" et éligibilité sortie = rstBProcessProbables(0) & ";" & rstBProcessProbables(1) & ";" & rstBProcessProbables(2) codeSQL = "INSERT INTO TEST(C1, C2, C3)VALUES " & rstBProcessProbables(0) & " , " & rstBProcessProbables(1) & " , " & rstBProcessProbables(2) DoCmd.RunSQL codeSQL ' On vérifie si le user est éligible. Si c'est le cas, onconcatène les zones séparées par des point-virgules End If
En parallèle j'ai crée une table TEST contenant les Champs C1, C2, C3 censés recevoir les données générées par le programme.
Le programme tourne mais s'arrête avec le message d'erreur "erreur de syntaxe dans l'instruction INSERT INTO". Le débogage se positionnant sur le

Code:

DoCmd.RunSQL codeSQL.

Quelle peut-être l'origine de l'erreur ??

Dagada75

15/11/2013, 11h56
loufab

Bonjour,

Forcément à la ligne 5 !

Ta syntaxe INSERT INTO est fausse. L'aide F1 ou MSDN donne les syntaxes.

Ici par exemple :
http://msdn.microsoft.com/en-us/libr...ffice.12).aspx

Il y a aussi un tuto qu'il faut que tu lises absolument. Celui sur le débogage des requêtes en VBA.

http://access.developpez.com/cours/?...gevba#vbadebug

Bonne lecture !
15/11/2013, 13h18
dagada75

Merci pour ton retour loufab

je me plonge dans cette lecture !

:)

Pour l'instant la syntaxe recommandée ne change rien au problème. Toujours le même message d'erreur .. humm

J'ai essayé
Code:

1 2 codeSQL = "INSERT INTO TEST VALUES " & rstBProcessProbables(0) & " , " & rstBProcessProbables(1) & " , " & rstBProcessProbables(2) DoCmd.RunSQL codeSQL
Car la structure de ma table reste inchangée (3 colonnes). Ca ne marche pas.

J'ai essayé
Code:

1 2 3 codeSQL = "INSERT INTO TEST [(C1 [, C2[, C3]])] VALUES " & rstBProcessProbables(0) & " , " & rstBProcessProbables(1) & " , " & rstBProcessProbables(2) DoCmd.RunSQL codeSQL
Ca ne marche pas non plus

J'ai essayé
Code:

1 2 3 codeSQL = "INSERT INTO TEST [(C1 [, C2[, C3]])] VALUES (" & rstBProcessProbables(0) & " [, " & rstBProcessProbables(1) & " [, " & rstBProcessProbables(2)]]) DoCmd.RunSQL codeSQL
non plus ...

Où se cache la vérité ? :aie:

16/11/2013, 23h40
dumas.blr

Attention, la syntaxe du sql est :

Code:

"INSERT INTO TEST(C1, C2, C3) VALUES (val1, val2, val3);"

en sachant que si les valeurs sont du texte, tu doit les mettre entre cotes
ex, si C1, C2 et C3 sont alphanumériques:

Code:

"INSERT INTO TEST(C1, C2, C3) VALUES ("a", "b", "c");"

Bon courage !

Voir 40 message(s) de cette discussion en une page