Join sur Array multidimentionnelle

re

franck j'ai testé 3000 lignes sur 20 colonnes avec des chaines de 20 caracteres dans chaque items

désolé index est plus rapide

attention j'ai bien presisé plus haut que je vidais et réinitialiser vba sinon c'est pas honnete comme résultat

parce que en relancant x fois la meme macro effectivement on a 1/2 voir 3 temps differents le 2d generalement plus court

dans tout les cas pour ce genre d'exercice meme sur x 000 lignes ca vaut pas le coup de se casser la tete ( je testerais 65635 lignes )

perso index etant une fonction interne a vba donc sure alors je m'en sert

c'est propre et net
toujours est il qu'il a tout ce qu'il lui faut pour tester decider et appliquer

les autres questions que vous vous posez, il ne l'a pas précisé donc ca n'est pas a l'ordre du jour et d'aucun interet ici

il a sa réponse
a lui de faire ces choix de methodes

Test de rapidité pour 4000 items:

-JoinArray() : 0,06 sec
-JoinArray2() [avec Index()]: 4 sec

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Sub essai() t = Timer Tbl = [A1:D1000] temp = JoinArray2(Tbl, ",") MsgBox Timer - t MsgBox Len(temp) End Sub   Function JoinArray(Tbl, Sep) For Each c In Tbl temp = temp & c & Sep Next c JoinArray = Left(temp, Len(temp) - 1) End Function   Function JoinArray2(Tbl, Sep) For i = 1 To UBound(Tbl) temp = temp & Join(Application.Index(Tbl, i), Sep) & Sep Next i JoinArray2 = Left(temp, Len(temp) - 1) End Function

---

Boisgontier

A Patrick :

Citation:

---

les autres questions que vous vous posez, il ne l'a pas précisé donc ca n'est pas a l'ordre du jour et d'aucun interet ici

---

Oh...
Il y a à plusieurs aspects, à savoir :
-le regard que l'on pose sur une question (le mien est visiblement différent du tien)
-la conscience personnelle (la mienne est peut-être différente de la tienne)
-le regard que l'on pose sur la vocation réelle d'un forum de développement (le mien est apparemment différent du tien)

Et la réponse fait intervenir ces trois aspects (appelle-les facteurs, si tu préfères).

Reste que les questions que j'ai posées l'ont été à jojo86 et que ce sont les réactions de jojo86 seul, que j'attends.
Il est pour l'instant muet ? C'est certes son droit. :sleep:
J'aurais au moins tenté de lui être vraiment utile au lieu de me contenter de le laisser faire du peut-être n'importe quoi (c'est là ma "religion" à moi. Après, il appartient à jojo86 (et à LUI SEUL) d'apprécier, de s'informer, ou de .... rester sur sa voie ... ).

Citation:

---

il a sa réponse
a lui de faire ces choix de methodes

---

Sauf si aucune de ces méthodes n'est ce qui est le plus approprié ... ce dont il aurait VRAIMENT besoin ...
Mais tant qu'il reste muet, ma foi ...

Citation:

---

Envoyé par unparia

Bonjour Franck
Tout-à-fait (tu as bien compris ma question).
Et les tenants également car si (en plus) les données de ce tableau dynamique sont le contenu d'une plage continue --->> nul besoin de la moindre boucle pour parvenir à cette "concaténation" (je ne veux pas utiliser ici le terme "Joining", non alors approprié) ;)
Donc : 2 questions :
1) la question essentielle : pour en faire quoi exactement ?
2) la question subsidiaire : comment ce tableau dynamique a-t-il été alimenté, très exactement ?

---

Bonsoir,
1 pour lister des champs et des valeurs afin de reconstituer dynamiquement une requête Insert SQL
2 j'ai un formulaire avec X composants. Les composants utiles au bon renseignement de la base ont un nom qui commence par "ZDyn" puis le nom du champ de la table. Par exemple, si j'ai un champ "Nom" dans ma table, alors mon champ sur le formulaire s'appellera "ZDynNom".

Avec une boucle, je parcours tous les objets de mon formulaire et si l'un des objets commence par "ZDyn" alors je récupère le nom du champ en supprimant "ZDyn" du nom de l'objet de cette manière j'ai bien uniquement le nom de mon champ "ZDynNom".
Je stock le nom du champ et sa valeur (qui correspond à la valeur de l'objet) dans la variable array.

Au final je dois pouvoir reconstituer :

Code:

---

Insert Into Table (Champ1, champ2, champ3...) Values (Valeur1, valeur2, valeur3)...

---

Je pourrais simplement utiliser 2 variables string l'une pour lister les champs et l'autre pour lister les valeurs mais je trouvais mieux d'utiliser une variable tableau.

Sinon j'aurais simplement pu faire :

Code:

---

1 2	ListeChamp = ListeChamp & NomObjetSansZDyn ListeValeurs = ListeValeurs & ValeurObjet

---

C'est peut être tordu comme truc, mais ça me permet grâce a cette astuce, de ne jamais faire de requêtes spécifiques pour faire mes insertions ou mes updates.
Je nomme mes objets et le code se débrouille du reste.
Avant ça, je devais pour chaque formulaire, faire des requête spécifiques ce qui peut prendre un temps monstrueux si on a une 30ene d'objets de saisie.

Par exemple, avant je devais nommer spécifiquement chaque objet dans ma requête :

Code:

---

Insert Into (Champ1, Champ2...) Values (TextBox1.Text, ListBox1.List(ListBox1.ListIndex,0)...)

---

Grâce à ce code, je n'ai plus besoin de saisir la requête en dur.

Sinon, j'ai l'impression que ça se tir dans les pâtes au sujet du Index... Je sais pas si le sujet en vaut bien la peine...

Citation:

---

Envoyé par patricktoulon

toujours est il qu'il a tout ce qu'il lui faut pour tester decider et appliquer

les autres questions que vous vous posez, il ne l'a pas précisé donc ca n'est pas a l'ordre du jour et d'aucun interet ici

il a sa réponse
a lui de faire ces choix de methodes

---

Sur ce point là je rejoins Patrick.
Maintenant, vue l'insistance, j'ai quand même développé un peu plus car je suis peut être a coté de la plaque.

Alors, Patrick ?
Tu as vu ?
Je te laisse maintenant la lui indiquer, la démarche adroite ...
;)

Citation:

---

Maintenant, vue l'insistance, j'ai quand même développé un peu plus car je suis peut être a coté de la plaque

---

jojo ne change pas la courge pour la courgette sous pretexte que d'autres aiment les carrottes

tu a le droit de te tromper ,bifurquer ,recommencer ,c'est comme ca qu'on apprends

Un coucou matinal, jojo86

Je t'invite ce matin à visiter le potager, donc (et tu pourras ensuite décider en meilleure connaissance de cause) :
- ouverture et lecture de la rubrique Déclaration de tableaux, histoire de voir quelle est l'occupation en mémoire d'un tableau à deux dimensions (et probablement de type variant, à moins que toutes tes données soienr du même type)
Et tu t'en sers comme tremplin, ce qui veut dire que :
1) tu dois l'alimenter (et tu dois là forcément soit parcourir les objets de ton formulaire, soit le faire au fur et à mesure)
pour
2) le traiter
afin de
3) construire une (en fait deux) chaîne(s) de caractères
et tout cela dans le but de :
4)

Citation:

---

Grâce à ce code, je n'ai plus besoin de saisir la requête en dur

---

(utiliser donc le résultat de l'exploitation faite en 3) pour l'insérer dans une requête)

Ne crois-tu pas que tout cela est un peu tiré par les cheveux et qu'existent des démarches (je ne vais pas ici dire "méthodes") moins lourdes et tout aussi efficaces ?
Je vais me contenter de te signaler la toute première d'entre elles (celle qui vient le plus facilement à l'esprit) :
- utiliser la propriété tag de chacun de tes objets de type "ZDynNom" et y mettre (lors de leurs évènements de saisie ou de sélection) la valeur correspondante de l'objet de saisie ou de sélection concerné.
- il est alors très simple de construire tes deux chaînes par simple parcours de ces objets (concaténation tant de la 1ère que de la seconde subordonnée à une propriété tag non vide)

Ce n'est là qu'une idée toute bête. Il en existe bien évidemment d'autres.

Bonjour,

Citation:

---

Envoyé par jojo86

Je pourrais simplement utiliser 2 variables string l'une pour lister les champs et l'autre pour lister les valeurs.

---

En effet, ce serait très certainement beaucoup plus simple que de manipuler une variable tableau pour finalement créer 2 String.

D'autant qu'ici nous ne t'avons proposé que de créer une seule variable String (comme quoi il faut absolument bien décrire le problème).

En tout cas, tu as des réponses et l'éventuel visiteur pour un cas non similaire aura également des réponses en ce qui concerne une éventuelle fonction JoinTableauMultidimensionnel.

Bonjour Franck
Pardi ...
Et je me demande ce qu'il adviendra (s'il ne prend pas tout de suite la bonne décision) le jour où il voudra peut-être pousser plus loin de bouchon et imiter le comportement/mécanisme de Informix , à savoir :
un seul écran pour les saisies, les insertions, les suppressions, les modifications, les requêtes (y compris complexes avec des OU, des ET, des ET OU, des OU ET, des LIKE, des BETWEEN etc...) et l'affichage des résultats ...
C'est MAINTENANT, qu'il lui faut choisir les bons rails, s'il ne veut pas avoir à tout reprendre ensuite à zéro.
Amitiés

Citation:

---

Envoyé par unparia

Un coucou matinal, jojo86

Je t'invite ce matin à visiter le potager, donc (et tu pourras ensuite décider en meilleure connaissance de cause) :
- ouverture et lecture de la rubrique Déclaration de tableaux, histoire de voir quelle est l'occupation en mémoire d'un tableau à deux dimensions (et probablement de type variant, à moins que toutes tes données soienr du même type)
Et tu t'en sers comme tremplin, ce qui veut dire que :
1) tu dois l'alimenter (et tu dois là forcément soit parcourir les objets de ton formulaire, soit le faire au fur et à mesure)
pour
2) le traiter
afin de
3) construire une (en fait deux) chaîne(s) de caractères
et tout cela dans le but de :
4)
(utiliser donc le résultat de l'exploitation faite en 3) pour l'insérer dans une requête)

Ne crois-tu pas que tout cela est un peu tiré par les cheveux et qu'existent des démarches (je ne vais pas ici dire "méthodes") moins lourdes et tout aussi efficaces ?
Je vais me contenter de te signaler la toute première d'entre elles (celle qui vient le plus facilement à l'esprit) :
- utiliser la propriété tag de chacun de tes objets de type "ZDynNom" et y mettre (lors de leurs évènements de saisie ou de sélection) la valeur correspondante de l'objet de saisie ou de sélection concerné.
- il est alors très simple de construire tes deux chaînes par simple parcours de ces objets (concaténation tant de la 1ère que de la seconde subordonnée à une propriété tag non vide)

Ce n'est là qu'une idée toute bête. Il en existe bien évidemment d'autres.

---

Salut, le tag je l’utilise pour specifier la «*quote*»(ca doit ps etre le bon mot. En gros dans le tag je précise de quel caractère je dois encadrer ma donnée. Lors de l´insert, pour du string le separateur sera ‘ pour une date le separateur sera # pour un nombre, pas de separateur.

Je vais modifier le code et oublier mon histoire de array. Mais j’aurai Au moins appris des choses et comme le dis Patrick, j’ai le deoit de me tromper!
Donc merci de votre aide. Je vais rester sur 2 variables string ca fait moins de manipulations.

Bonne journée a vous !!!

Citation:

---

En gros dans le tag je précise de quel caractère je dois encadrer ma donnée

---

Et alors ?
Au lieu d'y mettre par exemple le caractère ", qu'est-ce qui t'empêche d'y mettre directement la valeur à y mettre entourée de " ?
et qu'est-qui t'empêche d'ailleurs d'utiliser tout simplement le type du champ destinataire au lieu d'encombrer la propriété tag ?

Allez ... je vais te "passer" un petit truc que j'utilisais personnellement :

mes étiquettes de champs (tes "objets" de "type "ZDynNom") étaient "baptisés" de telle manière que leur nom seul indiquait déjà leur type (et donc tout ce qu'il faut pour encadrer éventuellement la valeur). Exemple avec tes objets et tes noms : Si Nom est un champ texte -->> ZDyn01Nom. Si champ date Zdyn02Nom, etc ...-->> on connaît ainsi le nom du champ : mid(nom_objet,6) et son type : mid(nom_objet,5,2)
J'espère que cela va te donner de bonnes idées.
Et si cela peut t'aider à encore plus de réflexion et de prise de décisions, j'y (dans le nom) incluais d'autres petites choses (champ obligatoire ou non, par exemple).
A toi de t'amuser et d'inventer, maintenant. ;)