Discussion :

[CyberLudo]

Bonjour,
J’ai besoin d’aide car je suis bloqué sur un truc qui me prend la tête depuis hier :

J’ai une Table nommée « TableTG »
Celle-ci se compose de 2 champs :
- « EQQL » qui est un champ texte contenant les références de mes commerciaux
- « Voie » qui est un champ mémo contenant les noms de rue
Voici un exemple de ma table :
EQQL Voie
0110 RUE D AVEJAN
0221 RUE BEAUTEVILLE
0110 PASSAGE CHAMPEYRACHE
0221 PLACE DU GENERAL LECLERC
0110 RUE PASTEUR


J’ai besoin en sortie d’avoir en sortie sur une nouvelle table :
EQQL Voies
0110 RUE D AVEJAN / PASSAGE CHAMPEYRACHE / RUE PASTEUR
0221 RUE BEAUTEVILLE / PLACE DU GENERAL LECLERC

Donc d’avoir dans un même champ regroupé sur EQQL, l’intégralité des enregistrements pour le champ « Voie ».

D’avance merci de votre aide…

Ludo

[fsmrel]

Bonsoir CyberLudo,


Vite fait sur le gaz :

Je vous propose une fonction en VBA, nommée Concatener. Pour la tester, j’ai utilisé un petit formulaire qui ne sert qu’à ça.

Le résultat de l’opération appliquée à la table TableTG se trouve dans une table nommée Concatenation (remise à zéro au chargement du formulaire, pour éviter les doublons au cours des tests).

Je joins le fichier .mdb correspondant.

A vous d’aménager selon vos besoins...

[CyberLudo]

Super tu me sauves la vie ! Merci encore et vive toi !

Ludo

[Pdg6704]

Super je cherchais également à réaliser chose semblable
mais je me suis aperçu que si la phrase contenait le caractère ' il y avait une erreur

1) voici l'exemple :

Bonsoir je teste le
caratère ' et çà bloque

-> Erreur 3075. Erreur de syntaxe (opérateur absent) dans l’expression ‘Bonsoir je teste le /caractère 'et çà bloque);

Comme solution j'ai remplacé le ' par " -> mais c'est pas joli, existe-t-il une solution ?

2) Serait-il possible d'avoir cela dans une macro et pas dans un formulaire ?

D'avance Merci

[Pdg6704]

Pour info je suis en access 2010
merci

[fsmrel]

Bonsoir Pdg6704,

Erreur 3075. Erreur de syntaxe (opérateur absent)

Il est un fait que SQL interprète « ' » comme caractère de fin de chaîne et donc attend un opérateur à la suite... Je pense pouvoir régler ça dès que.


Je vous tiens au courant.

[fsmrel]

Voilà, c’est fait. Depuis toujours, SQL demande que l’on double les caractères de fin de chaîne (apostrophes) qui se promènent dans les chaînes de caractères, j‘ai donc utilisé la fonction REPLACE pour remédier :

x = REPLACE(w, "'", "''")

Les apostrophes sont préservées dans le résultat (table Concatenation).

Je joins le fichier .mdb correspondant.


Merci de me tenir au courant.

François

[Pdg6704]

Merci François, c'est très bien et cela fonctionne.

J'ai fait l'implémentation dans ma base, il y a plus des 10000 lignes pour le test ensuite 1250000 lignes

J'ai quelques différences avec la toute première demande, en effet

1)chez moi le champ voie peut contenir des blancs : le ficher est comme cela au départ (j'aurais juste un espace en plus dans le champs voies ou alors tester le champs voie et si c'est vide et ne pas en tenir compte, ce serait plus propre)
2) Il faudrait en plus tenir compte du champs Type, le champs Type à 4 valeurs , T,C,M et Blanc -> il faudrait prendre les EQQL qui sont du type T uniquement

3) le champ voies doit être du type mémo car le texte est parfois >255 caratères et quand on a fini de concatéter et il manque donc du texte

Je n'ai pas compris pourquoi il y avait 2 clés primaires dans ta TablesTG-> je les ai supprimées pour pouvoir intégrer les cases blanches et mis les champs sur chaine vide autorisé
j'ai aussi modifié la ligne
w = Left(theChaine, Len(theChaine) - 1) avant c'était -3 est cela coupait certaine partie de phrase (y avait-il une raison de mettre 3 )
j'ai remplacé le " / " par " " car dans mon cas ce n'est pas necessaire.

Voilà peux-tu analyser ma demande ?

Merci
Thierry

[fsmrel]

Ave Thierry,


On fait dans le sur mesure

Je m'en occupe.

[fsmrel]

Bonsoir Thierry,

le champ Voie peut contenir des blancs

J’interprète cela comme une ligne pout laquelle l’attribut Voie ne contient que du « blanc » Dans ces conditions, je commencerai par faire un TRIM de chaque chaîne lue. Si au résultat la longueur est égale à zéro, je ne créerai pas de ligne dans la table Concatenation.

il faudrait prendre les EQQL qui sont du type T uniquement

Autrement dit, vous souhaitez mettre en œuvre un attribut TypeEQQL : soit.

le champ Voie doit être du type mémo car le texte est parfois >255 caractères

D’accord. Mais lors de la lecture de la colonne, ce c... d’ACCESS tronque à 255 caractères, sauf si on lit bestialement (OpenRecordset("TableTG", dbOpenDynaset)). C’est plus lourd et plus lent. Vous me direz si vos performances en souffrent...

Je n'ai pas compris pourquoi il y avait 2 clés primaires dans ta TablesTG-> je les ai supprimées pour pouvoir intégrer les cases blanches et mis les champs sur chaine vide autorisé

Par définition, une table n’a qu’une clé primaire. En l’occurrence, il s’agit de la paire {EQQL, Voie}. Supprimons la clé primaire, mais alors TablesTG n’est plus une table au sens relationnel, elle dégénère en « sac », c'est-à-dire une chose où l’on peut avoir des lignes en double, et où l'on ne se soucie pas de la présence du bonhomme Null. Un sac n’est pas manipulable par l’algèbre relationnelle. Mais c’est vous qui voyez...

y avait-il une raison de mettre 3

Oui, car Ludo souhaitait séparer par « / » les éléments concaténés (espace, slash, espace). Donc on retrouvait inutilement ce trio en fin de chaîne, d’où son élimination.


Et n’oubliez pas de voter pour les réponses qui ont pu vous être utiles...


Ci-joint la dernière mouture.

[fsmrel]

Bonsoir Thierry,

Lors de la lecture de la colonne, ce c... d’ACCESS tronque à 255 caractères, sauf si on lit bestialement (OpenRecordset("TableTG", dbOpenDynaset)). C’est plus lourd et plus lent. Vous me direz si vos performances en souffrent...

Bon, finalement, en partant de scratch, j’arrive à utiliser un recordset filtrant, sans troncature à 255 caractères, donc les performances devraient être meilleures avec le fichier .mdb que je joins ici. Sinon, mystère, je n’ai toujours pas compris pourquoi Access tronquait, alors que le code est identique à un poil près...

[Pdg6704]

Bonjour François merci pour ton travail

J'ai testé les deux possibilités "Voiecontact A et Voiecontact V, effectivement cela prend du temps tu as raison (pour 120000 données il faut plus d'une heure.
Pour l'instant je teste ta dernière solution (version du 16/08) çà vient de se terminer en 35min

Une petite remarque concernant l'interprétation des lignes blanches

>>>Envoyé par Pdg6704
>>>le champ Voie peut contenir des blancs
-> J’interprète cela comme une ligne pour laquelle l’attribut Voie ne contient que du « blanc » Dans ces conditions, je commencerai par faire un TRIM de chaque chaîne lue. Si au résultat la longueur est égale à zéro, je ne créerai pas de ligne dans la table Concatenation.
>>>>Envoyé par Pdg6704
il faudrait prendre les EQQL qui sont du type T uniquement
Autrement dit, vous souhaitez mettre en œuvre un attribut TypeEQQL : soit.

Je me suis sans doute mal exprimé -> Il faut prendre tous les enregistrements EQQL qui on le type "T" ça c'est juste et les mettre dans concaténation même s'il y a des valeurs dans le champ voie qui sont à blanc. C’est pour éviter Texte 1 / / / texte x et n’avoir que Texte 1 / texte x
Parce qu'après je dois savoir combien il y a "de réponses" dans le cas ci-dessous j'aurai 2 réponses sur 3 soit 66,66%
exemple
0200 T Bonjour
0200 T
0200 M 1254687
0200 T François
0210 T
0300 T Merci
0301 C possible
0301 T Bien

cela devrait donner dans concatenation
0200 Bonjour / François
0210
0300 Merci / Bien

Encore super pour le développement avec moitié de temps..

[fsmrel]

Bonsoir Thierry,

même s'il y a des valeurs dans le champ voie qui sont à blanc

D’accord. Côté SQL c’est moins filtrant, par conséquent la durée du traitement risque de s’allonger... A propos des performances, il faut veiller à ce que la colonne EQQL de la table soit indexée, sinon la durée est considérablement accrue.

Les résultats avec le nouveau fichier . mdb que je joins sont-ils corrects ? Que deviennent les perfs ? Pour exécuter : cliquer sur le formulaire.

[Pdg6704]

Bonjour François,
j'ai fait le test avec cette version, en gardant la colonne EQQL indexée. Pour traiter les 120000 lignes, il faut +/-6min (une fois en 369sec et une fois 349).
Pour moi c'est vraiment parfait, et cela me convient bien comme cela.

je vais poursuivre en intégrant complètement ton module dans mabase.

Encore un grand merci pour tes réalisations, cela va m'aider énormement

Bien à toi
Thierry

[fsmrel]

Bonne route Thierry ! S'il y a un problème, tu connais la maison