Quel fichier Input pour VB.net

Bonjour

On a une application qui lit des fichiers excel en entrée, y rajoute quelques informations provenant de tables et produit un nouvel fichier excel, puis à l'aide d'un utilitaire, elle convertit ce nouveau fichier excel en un fichier pdf.

entrée : Fichier excel
Sortie : fichier en format PDF

On trouve que Excel cause assez de problèmes dans la standardisation des formulaires en francais et en anglais, et aussi les cases se dilatent et provoquent un débordement sur d'autres cellules.

On cherche un autre type de fichier en entrée

La sortie doit rester en format PDF.

Merci d'avance.

Pourquoi ne pas faire l'entrée en XML ? c'est un format très facile à manoeuvrer avec .NET et assez facile à modifier à la main. Il serai très éfficace je pense mais par contre pour la génération du PDF après je ne sais pas ...

Le XML peut être une solution... sinon essaye le CSV, c'est un format standard et très simple à comprendre et manipuler (faut bien maîtriser le substring par contre;)).

En plus tu auras l'avantage de pouvoir l'ouvrir avec excel pour vérifier tes résultats.

Citation:

---

Envoyé par The eye

Le XML peut être une solution... sinon essaye le CSV, c'est un format standard et très simple à comprendre et manipuler (faut bien maîtriser le substring par contre;)).

.

---

Le CSV pose justement des problèmes permanents d'internationalisation. Assez mauvais conseil, AMHA.

Citation:

---

Envoyé par Bluedeep

Le CSV pose justement des problèmes permanents d'internationalisation. Assez mauvais conseil, AMHA.

---

quel genre de problèmes?

Citation:

---

Envoyé par The eye

quel genre de problèmes?

---

Un export CSV en culture EN donne

123.45 , "gsdhfqhsg", "jhjhlhjhlkhkl"

le même en FR donne :

"123,45" , "gsdhfqhsg", "jhjhlhjhlkhkl"

(ou quelque chose d'approchant).

Mieux vaut utiliser des séparateurs "tab" à la rigueur.
Par ailleurs le format CSV du Clipboard fonctionne très mal avec Excel, pour une raison que je n'ai jamais comprise. (et pas approfondi non plus, à vrai dire).

Bref, avoir un format de fichier dont l'interprétation des éléments de format (ici la virgule) est équivoque avec des éléments de contenu me semble un choix peu pertinent.

Citation:

---

Envoyé par smyley

Pourquoi ne pas faire l'entrée en XML ? c'est un format très facile à manoeuvrer avec .NET et assez facile à modifier à la main. Il serai très éfficace je pense mais par contre pour la génération du PDF après je ne sais pas ...

---

C'est parce que les fichiers d'entrées proviennent de plusieurs personnes différentes (environ 50 personnes) et il va falloir que tout ce monde se conforme à cette nouvelle règle.

Actuellement toutes ces personnes ont l'habitude de produire leurs fichier en Excel.

Citation:

---

Envoyé par Bluedeep

Un export CSV en culture EN donne

123.45 , "gsdhfqhsg", "jhjhlhjhlkhkl"

le même en FR donne :

"123,45" , "gsdhfqhsg", "jhjhlhjhlkhkl"

(ou quelque chose d'approchant).

Mieux vaut utiliser des séparateurs "tab" à la rigueur.
Par ailleurs le format CSV du Clipboard fonctionne très mal avec Excel, pour une raison que je n'ai jamais comprise. (et pas approfondi non plus, à vrai dire).

Bref, avoir un format de fichier dont l'interprétation des éléments de format (ici la virgule) est équivoque avec des éléments de contenu me semble un choix peu pertinent.

---

1 - le paramétrage du séparateur de décimal est un paramètre windows réglable. Donc le meilleur séparateur reste le ";"

2 - ton problème de clipboard qui fonctionne mal avec Excel est dû à la non reconnaissance du séparateur CSV (paramétrable dans Excel...)

De plus on a besoin de conserver l'utilisation d'Excel par les clients (si j'ai bien compris...) donc il suffit de leur spécifier de sauvegarder leur fichiers Excel en CSV et HOP le tour est joué.

Au vue de tes arguments ma proposition ne me semble pas si mauvaise finalement :D

Citation:

---

Envoyé par The eye

1 - le paramétrage du séparateur de décimal est un paramètre windows réglable. Donc le meilleur séparateur reste le ";"

---

Je te remercie pour cette information précieuse :D
Blague à part, le problème que je soulevais c'est que les échanges via CSV entre système de cultures installées différentes, c'est potentiellement fumeux.

Citation:

---

2 - ton problème de clipboard qui fonctionne mal avec Excel est dû à la non reconnaissance du séparateur CSV (paramétrable dans Excel...)

---

Très joli, mais, non, ce n'est pas cela; je te suggère de faire l'essai, en chargeant le Clipboard en CSV par programme via l'objet éponyme et en faisant ensuite un Ctrl-C dans ta feuille excel (par ailleurs tu ne peux pas décemment faire l'hypothèse de sélection de culture par le client, ni d'égalité de culture entre le provider de données et le consommateur).

Le ";" pose aussi le problème d'ambigüité séparateur/données contenues.
Aucun format CSV ne constitue une solution fiable à 100%, seulement des solutions qui marchent parfois. (par exemple, un CSV avec que des valeurs entières va marcher presque à coup sur - dès l'instant où tu as du texte et des décimaux, c'est pas gagné à tous les coups - sans même parler des problèmes de sélection de jeu de caractères, difficile à régler).

Citation:

---

De plus on a besoin de conserver l'utilisation d'Excel par les clients (si j'ai bien compris...) donc il suffit de leur spécifier de sauvegarder leur fichiers Excel en CSV et HOP le tour est joué.

---

Bis : comment gères tu la non homogénéité de Culture entre les systèmes ?

Citation:

---

Envoyé par The eye

De plus on a besoin de conserver l'utilisation d'Excel par les clients (si j'ai bien compris...) donc il suffit de leur spécifier de sauvegarder leur fichiers Excel en CSV et HOP le tour est joué.

---

Si par exemple on n'avait pas besoin de conserver un fihier excel en entrée et aussi de ne pas conserver un fichier PDF en sortie, qu'est ce que tu propeserais ?

Condition : les fichiers d'entrée des client peuvent être différent d'un client à un autre. Aussi L'application VB.net devrait rajouter quelques informations qui sont différentes d'un client à un autre et on ne veut pas les hardcoder (ce qui se passe actuellement). On cherche un genre de système générique qui répondra au besoin de tous les clients.

Citation:

---

Envoyé par DEV-10

Si par exemple on n'avait pas besoin de conserver un fihier excel en entrée et aussi de ne pas conserver un fichier PDF en sortie, qu'est ce que tu propeserais ?

---

Sans données d'entrées et sans données de sorties, les applications sont en effet beaucoup plus simples :mouarf:

Citation:

---

Condition : les fichiers d'entrée des client peuvent être différent d'un client à un autre. Aussi L'application VB.net devrait rajouter quelques informations qui sont différentes d'un client à un autre et on ne veut pas les hardcoder (ce qui se passe actuellement). On cherche un genre de système générique qui répondra au besoin de tous les clients.

---

Peux tu détailler ton besoin fonctionnel de manière plus précise ? On t'aidera surement à trouver une solution.

Citation:

---

Envoyé par Bluedeep

Sans données d'entrées et sans données de sorties, les applications sont en effet beaucoup plus simples :mouarf:



Peux tu détailler ton besoin fonctionnel de manière plus précise ? On t'aidera surement à trouver une solution.

---

C'est que maintenant l'application vb.net recois des fichiers Excel, fait un traitement et après, elle produit des fichiers PDF.

Contenu du traitement : Chaque fichier excel que l'application recoit de la part du client elle y rajoute quelques données comme l'adresse, le nom, les produits qui vendent , ect. mais ces rajouts sont différent d'un client à un autre.

Exemple :

pour le client 1 : on rajoute ses coordonnées (se trouvant dans une table) et on rajoute l'item A et l'item B

pour le client 2 : on rajoute ses coordonnées (se trouvant dans une table) et on rajoute l'item C et l'item D et l'item E

pour le client 3 : on rajoute ses coordonnées (se trouvant dans une table) et on rajoute l'item F et l'item G

actuellement, on le hard code pour chaque type de client, et ça devient rudimentaire avec le nombre de client qui ne cesse d'augmenter.

Citation:

---

Envoyé par DEV-10

C'est que maintenant l'application vb.net recois des fichiers Excel, fait un traitement et après, elle produit des fichiers PDF.

Contenu du traitement : Chaque fichier excel que l'application recoit de la part du client elle y rajoute quelques données comme l'adresse, le nom, les produits qui vendent , ect. mais ces rajouts sont différent d'un client à un autre.

Exemple :

pour le client 1 : on rajoute ses coordonnées (se trouvant dans une table) et on rajoute l'item A et l'item B

pour le client 2 : on rajoute ses coordonnées (se trouvant dans une table) et on rajoute l'item C et l'item D et l'item E

pour le client 3 : on rajoute ses coordonnées (se trouvant dans une table) et on rajoute l'item F et l'item G

actuellement, on le hard code pour chaque type de client, et ça devient rudimentaire avec le nombre de client qui ne cesse d'augmenter.

---

J'ai oublié de rajouter que le fichier de sortie doit être en format PDF (pour question de sécurité et d'agrégation)

Bon, ok, mais une chose que je ne comprends pas.

Il me semble que tu veuilles lire des données d'un fichier Excel, en fonction de la provenance de ce fichier agréger une ou plusieurs info et générer un Pdf; ça c'est clair. Ce qui ne l'est pas, en revanche, c'est pourquoi veux tu modifier le fichier Excel ??? j'avoue que je ne comprends pas, car, pour moi, dans ce cas, la réponse à priori évidente c'est :

- lire les données du fichier (via Interop, etc ... cf. tutoriel)

- agréger les données supplémentaires.

- générer un Pdf avec le tout (avec ITextSharp par exemple).

Et c'est tout.

Donc je ne vois aucune espèce d'utilité à la phase d'ajout de données au fichier Excel, ou alors tu as oublié de nous dire quelque chose.

Citation:

---

Envoyé par Bluedeep

Bon, ok, mais une chose que je ne comprends pas.

Il me semble que tu veuilles lire des données d'un fichier Excel, en fonction de la provenance de ce fichier agréger une ou plusieurs info et générer un Pdf; ça c'est clair. Ce qui ne l'est pas, en revanche, c'est pourquoi veux tu modifier le fichier Excel ??? j'avoue que je ne comprends pas, car, pour moi, dans ce cas, la réponse à priori évidente c'est :

- lire les données du fichier (via Interop, etc ... cf. tutoriel)

- agréger les données supplémentaires.

- générer un Pdf avec le tout (avec ITextSharp par exemple).

Et c'est tout.

Donc je ne vois aucune espèce d'utilité à la phase d'ajout de données au fichier Excel, ou alors tu as oublié de nous dire quelque chose.

---

Faisons un exemple :
le client x rédige un seul formulaire pour l'envoyer à 5000 répondants.
Ce formulaire contient de l'information qui est parreil pour tous les répondants.
Mais il y a de l'information qui diffère d'un répondant à un autre. exemple : le nom et l'adresse du répondant qui sont habituellement sur la première page. mais aussi d'autres informations qui sont au milieu du formulaire (onglet 6 par exemple)
Le client veut écrire une seule fois le formulaire excel et il veut que notre application VB.net rajoute les informations sur les 5000 formulaires en retirant les données d'une base de donnée.
ça c'est juste pour le client x. Il y a plusieurs clients qui ont plusieurs formulaires chacun.
et la page d'un fichier excel(elastique) ne correspont pas à une page de papier.
On veut trouver alors un fichier d'entrée standard qui sera le même pour tous les clients.
ce fichier sera soumis à l'application VB pour y rajouter de l'info automatiquement et non par hardcodage.

Mais je ne comprends pas le besoin de garder les formulaires Excel ici !!!

Quand on récupère les formulaires, on a les données dedans, donc on traites les données et on les stocke. Donc quelle est la raison de modification des fichiers excel ? c'est plus que flou au bas mot.

Citation:

---

Envoyé par Bluedeep

Mais je ne comprends pas le besoin de garder les formulaires Excel ici !!!.

---

Qu'est ce que tu veux dire par le besoin de garder le formulaire ?

Citation:

---

Envoyé par Bluedeep

Quand on récupère les formulaires, on a les données dedans, donc on traites les données et on les stocke. Donc quelle est la raison de modification des fichiers excel ? c'est plus que flou au bas mot.

---

Faut faire la différence entre le client et le répondant

Il y a plusieurs sortes de données.
1) les questions écritent par le client pour une multitude de catégiorie de répondants. à ce stade le formulaire qui nous a été fourni par le client ne contient pas les coordonnées des répondants.

2) Les informations écritent par l´application vb.net (comme les coordonnées des répondants)

3) les réponses des répondants aux questions du client.

C'est un sondage qui est envoyé par la poste à des milliers de répondants.
Est-ce que c'est plus clair ?

Citation:

---

Envoyé par DEV-10

C'est un sondage qui est envoyé par la poste à des milliers de répondants.
Est-ce que c'est plus clair ?

---

C'est tout à fait clair, mais je persiste : je ne vois pas l'intérêt ici de garder les fichiers Excel. (d'autant qu'il semble qu'on duplique l'information dans des report pdf, si j'ai bien compris).

Quelque chose doit m'échapper dans votre process, ou dans votre flux de données.

Citation:

---

Envoyé par Bluedeep

C'est tout à fait clair, mais je persiste : je ne vois pas l'intérêt ici de garder les fichiers Excel. (d'autant qu'il semble qu'on duplique l'information dans des report pdf, si j'ai bien compris).

Quelque chose doit m'échapper dans votre process, ou dans votre flux de données.

---

Ils utilisent un utilitaire qui convertit un fichier excel en pdf, il faut donc faire le fichier excel comme ils le souhaitent et ensuite le convertir en fichier pdf.

Citation:

---

pour le client 1 : on rajoute ses coordonnées (se trouvant dans une table) et on rajoute l'item A et l'item B
pour le client 2 : on rajoute ses coordonnées (se trouvant dans une table) et on rajoute l'item C et l'item D et l'item E
pour le client 3 : on rajoute ses coordonnées (se trouvant dans une table) et on rajoute l'item F et l'item G

---

C'est codé en dur, si je comprends bien ça veut dire que pour chaque client il y a les instructions à faire. Et vous voulez généraliser tout ça pour ne pas devoir modifier l'application lorsqu'un nouveau client apparait ?

Citation:

---

Envoyé par goomazio

Ils utilisent un utilitaire qui convertit un fichier excel en pdf, il faut donc faire le fichier excel comme ils le souhaitent et ensuite le convertir en fichier pdf.

---

Oui l'utilitaire s'appelle PDF995

Citation:

---

Envoyé par goomazio

C'est codé en dur, si je comprends bien ça veut dire que pour chaque client il y a les instructions à faire. Et vous voulez généraliser tout ça pour ne pas devoir modifier l'application lorsqu'un nouveau client apparait ?

---

Tout à fait !

Quels sont les critères utilisés pour déterminer les informations à ajouter au fichier excel ? Il est peut-être possible de trouver une logique dans ce choix... et l'automatiser.

Sinon, sans information sur ces critères, ou s'il n'y a aucune logique, on pourrait trouver une solution permettant de faire cela mais elle ne sera pas totalement automatique. Il faudra toujours définir manuellement quelque chose, mais à la place de définir cela dans le code et devoir recompiler l'application, il serait possible d'utiliser un fichier XML par exemple, ou en utilisant le SGBD (exemple : les items à ajouter sont précédés d'une astérisque).

Citation:

---

Envoyé par goomazio

Quels sont les critères utilisés pour déterminer les informations à ajouter au fichier excel ? Il est peut-être possible de trouver une logique dans ce choix... et l'automatiser.

---

Ce qui est toujours certain c'est :

- le nom et l'adresse du répondant (on les tire maintenant d'une bases de données Access qu'on veut migrer vers SQL 2005)

Le reste je te reviendrais la-dessus (je dois vérifier queque chose avant)

Citation:

---

Envoyé par goomazio

Sinon, sans information sur ces critères, ou s'il n'y a aucune logique, on pourrait trouver une solution permettant de faire cela mais elle ne sera pas totalement automatique. Il faudra toujours définir manuellement quelque chose, mais à la place de définir cela dans le code et devoir recompiler l'application, il serait possible d'utiliser un fichier XML par exemple, ou en utilisant le SGBD (exemple : les items à ajouter sont précédés d'une astérisque).

---

Étant donné que le client lui même ne peut pas savoir tous les ajouts qui auront lieu et quand, il faudrait trouver une option semi-générique.
Peux-tu détailler l'option XML ?
Y a t-il d'autres types de format qu'on peut utiliser en entrée autre que les fichiers XML. La sortie doit par exemple rester en PDF.

Citation:

---

Envoyé par DEV-10

Étant donné que le client lui même ne peut pas savoir tous les ajouts qui auront lieu et quand, il faudrait trouver une option semi-générique.
Peux-tu détailler l'option XML ?

---

Je précise que je parle de fichier XML non pas comme de fichiers d'entrée mais d'un fichier définissant les champs à ajouter pour chaque client : à la place de définir cela dans le code, en dur, et de devoir modifier l'application à chaque ajout de client, on définit cela dans un fichier XML. Ce n'est donc pas une solution d'automatisation en fait.

Si on a la table client suivante :
CLIENT
------
Id
Nom
Prenom
Adresse
DateDeNaissance

et que pour le client Id = 1, on veut ajouter la date de naissance, et que pour le client Id = 2 on veut ajouter le prénom et la date de naissance, à la place de le définir dans le code en écrivant

Code:

---

1 2 3 4 5 6 7

SI Client.Id == 1 ALORS ajouter Client.DateDeNaissance SINON SI Client.Id == 2 ALORS ajouter Client.Prenom ajouter Client.DateDeNaissance FIN SI

---

on écrirait dans un fichier XML :

Citation:

---

<client1>DateDeNaissance</client1>
<client2>Prenom;DateDeNaissance</client2>

---

et dans l'application on écrirait

Code:

---

1 2 3 4 5

POUR Chaque Client Recherche dans le fichier XML les champs à ajouter Ajout des champs à ajouter FIN POUR

---

Citation:

---

Envoyé par DEV-10

Y a t-il d'autres types de format qu'on peut utiliser en entrée autre que les fichiers XML. La sortie doit par exemple rester en PDF.

---

Je ne comprends pas le problème que pose excel mais peut-être en utilisant une base de données comme Access ou Open Office Base en entrée, ce sera plus facile pour les clients que d'utiliser excel ou un fichier XML, mais par contre ce sera plus difficile à mettre en place : mettre Access ou Open Office Base sur les machines clientes (quoi que si excel est installé chez le client, access l'est peut-être aussi) et transformer la lecture de fichiers excel par une lecture de base de données...

Citation:

---

Envoyé par goomazio

Je précise que je parle de fichier XML non pas comme de fichiers d'entrée mais d'un fichier définissant les champs à ajouter pour chaque client : à la place de définir cela dans le code, en dur, et de devoir modifier l'application à chaque ajout de client, on définit cela dans un fichier XML. Ce n'est donc pas une solution d'automatisation en fait.

Si on a la table client suivante :
CLIENT
------
Id
Nom
Prenom
Adresse
DateDeNaissance

et que pour le client Id = 1, on veut ajouter la date de naissance, et que pour le client Id = 2 on veut ajouter le prénom et la date de naissance, à la place de le définir dans le code en écrivant

Code:

---

1 2 3 4 5 6 7

SI Client.Id == 1 ALORS ajouter Client.DateDeNaissance SINON SI Client.Id == 2 ALORS ajouter Client.Prenom ajouter Client.DateDeNaissance FIN SI

---

on écrirait dans un fichier XML :
et dans l'application on écrirait

Code:

---

1 2 3 4 5

POUR Chaque Client Recherche dans le fichier XML les champs à ajouter Ajout des champs à ajouter FIN POUR

---

Je n'ai pas compris le problème que pose excel mais peut-être en utilisant une base de données comme Access ou Open Office Base en entrée, ce sera plus facile pour les clients que d'utiliser excel ou un fichier XML, mais par contre ce sera plus difficile à mettre en place : mettre Access ou Open Office Base sur les machines clientes (quoi que si excel est installé chez le client, access l'est peut-être aussi) et transformer la lecture de fichiers excel par une lecture de base de données...

Sinon, développer une application qui permettrait de créer les fichiers XML, on aurait l'avantage du XML sans avoir l'inconvénient de devoir former tout le monde. Ca ressemblerait à un tableur, quand on sauvegarde ça crée le fichier XML, et il serait bien sur très simple : il ne permettrait que l'encodage des données.

---

Ok je vais faire quelques vérifications et je tiendrais au courant de la suite dès que possible.
as tu un exemple d'une application qui crée des fichiers XML

Merci bien.

Citation:

---

Envoyé par Bluedeep

Le problème que je soulevais c'est que les échanges via CSV entre système de cultures installées différentes, c'est potentiellement fumeux.

---

Exemple?

Citation:

---

Envoyé par Bluedeep

Très joli, mais, non, ce n'est pas cela; je te suggère de faire l'essai, en chargeant le Clipboard en CSV par programme via l'objet éponyme et en faisant ensuite un Ctrl-C dans ta feuille excel (par ailleurs tu ne peux pas décemment faire l'hypothèse de sélection de culture par le client, ni d'égalité de culture entre le provider de données et le consommateur).

---

C'est parceque j'ai fait l'essai que je sais que cela est possible... tu crois que je balance des infos au hasard en espérant tomber juste?

Citation:

---

Envoyé par Bluedeep

Le ";" pose aussi le problème d'ambigüité séparateur/données contenues.

---

Question de formation : il faut expliquer au client qu'il ne peuvent pas remplir leur fichier comme il veulent, qu'il y a des règles à appliquer. Après cela pas de problème

Citation:

---

Envoyé par Bluedeep

Aucun format CSV ne constitue une solution fiable à 100%, seulement des solutions qui marchent parfois.

---

Conclusion : c'est FAUX! il y a des solutions viables et internationales VIA CSV. Il faut juste BIEN connaître les principes de fonctionnement qui en détermine les limites.

Citation:

---

Envoyé par DEV-10

Si par exemple on n'avait pas besoin de conserver un fihier excel en entrée et aussi de ne pas conserver un fichier PDF en sortie, qu'est ce que tu propeserais ?

---

Le XML... pour sa souplesse et sa bonne intégration dans le .NET

Citation:

---

Envoyé par The eye

Question de formation : il faut expliquer au client qu'il ne peuvent pas remplir leur fichier comme il veulent, qu'il y a des règles à appliquer. Après cela pas de problème

---

Oui, on est entrain de travailler la-sessus avec les clients, car ils faut que certaines règles soient respectées lors de la conception de leurs formulaires.

Bon si on en revenait au problème ?

Tiens d'ailleurs si je peux apporter ma contribution, tu peux garder le format Excel sans passer par de l'interop mais en demandant aux utilisateurs de sauvegarder le fichier Excel au format XML-Excel (je n'ai plus la dénomination exacte dans Excel). Tes utilisateurs conservent Excel pour faire leur fichier et toi tu as de l'XML à traiter. Le format XML des fichiers Excel est simple à gérer, tu ne devrais pas rencontrer de problèmes majeurs, ça ressemble à de l'HTML.

C'est pas une belle solution ça ? ;)

Citation:

---

Envoyé par SaumonAgile

Tiens d'ailleurs si je peux apporter ma contribution, tu peux garder le format Excel sans passer par de l'interop mais en demandant aux utilisateurs de sauvegarder le fichier Excel au format XML-Excel (je n'ai plus la dénomination exacte dans Excel). Tes utilisateurs conservent Excel pour faire leur fichier et toi tu as de l'XML à traiter. Le format XML des fichiers Excel est simple à gérer, tu ne devrais pas rencontrer de problèmes majeurs, ça ressemble à de l'HTML.

C'est pas une belle solution ça ? ;)

---

Merci. Je vais aller faire un exemple et te revenir après.

[quote=goomazio;2832263]Je précise que je parle de fichier XML non pas comme de fichiers d'entrée mais d'un fichier définissant les champs à ajouter pour chaque client : à la place de définir cela dans le code, en dur, et de devoir modifier l'application à chaque ajout de client, on définit cela dans un fichier XML. Ce n'est donc pas une solution d'automatisation en fait.

Si on a la table client suivante :
CLIENT
------
Id
Nom
Prenom
Adresse
DateDeNaissance

et que pour le client Id = 1, on veut ajouter la date de naissance, et que pour le client Id = 2 on veut ajouter le prénom et la date de naissance, à la place de le définir dans le code en écrivant

Code:

---

1 2 3 4 5 6 7

SI Client.Id == 1 ALORS ajouter Client.DateDeNaissance SINON SI Client.Id == 2 ALORS ajouter Client.Prenom ajouter Client.DateDeNaissance FIN SI

---

on écrirait dans un fichier XML :
et dans l'application on écrirait

Code:

---

1 2 3 4 5

POUR Chaque Client Recherche dans le fichier XML les champs à ajouter Ajout des champs à ajouter FIN POUR

---

C'est une bonne idée en soi, sauf que pour les champs à ajouter, comment tu pense les insérer dans le fichier excel pour chaque client afin qu'ils soient lus par l'application ? on parle d'une dizaine d'item à ajouter mais pour des milliers de répondants.

Citation:

---

Envoyé par SaumonAgile

Tiens d'ailleurs si je peux apporter ma contribution, tu peux garder le format Excel sans passer par de l'interop mais en demandant aux utilisateurs de sauvegarder le fichier Excel au format XML-Excel (je n'ai plus la dénomination exacte dans Excel). Tes utilisateurs conservent Excel pour faire leur fichier et toi tu as de l'XML à traiter. Le format XML des fichiers Excel est simple à gérer, tu ne devrais pas rencontrer de problèmes majeurs, ça ressemble à de l'HTML.

C'est pas une belle solution ça ? ;)

---

J'ai fais un petit exemple et il a l'air de bien marcher.
Puisqu'on traite des milliers de formulaires, le client lui même ne connait pas toujours les ajouts qui seront fait au formulaire de base pour les diférents répondants et on ne peut pas les rajouter manuellement parce que ça être long.

Citation:

---

Envoyé par smyley

Pourquoi ne pas faire l'entrée en XML ? c'est un format très facile à manoeuvrer avec .NET et assez facile à modifier à la main. Il serai très éfficace je pense mais par contre pour la génération du PDF après je ne sais pas ...

---

Dans ce cas, il faut que les concepteurs connaissent XML pour pouvoir le manipuler.

Si on sauve leurs fichiers Excel en format XML, qu'est ce que tu pourrais me dire la-dessus ?

Citation:

---

Envoyé par SaumonAgile

Tiens d'ailleurs si je peux apporter ma contribution, tu peux garder le format Excel sans passer par de l'interop mais en demandant aux utilisateurs de sauvegarder le fichier Excel au format XML-Excel (je n'ai plus la dénomination exacte dans Excel). Tes utilisateurs conservent Excel pour faire leur fichier et toi tu as de l'XML à traiter. Le format XML des fichiers Excel est simple à gérer, tu ne devrais pas rencontrer de problèmes majeurs, ça ressemble à de l'HTML.

C'est pas une belle solution ça ? ;)

---

Bonjour SaumonAgile

Je suis en train de penser à cette alternative et aimerais te demander plus d'explication si tu en as.
le format de sauvegarde est est : SpreadSheet (*.xml)

Le plus simple est que tu te crées un fichier excel que tu enregistres en format XML et que tu regardes comment se présente l'XML généré en fonction des données du fichier.

Citation:

---

Envoyé par SaumonAgile

Le plus simple est que tu te crées un fichier excel que tu enregistres en format XML et que tu regardes comment se présente l'XML généré en fonction des données du fichier.

---

C'est en fait ce que je suis en train de faire, mais je me demande aussi que VB.net peut lire aussi bien des fichiers Excel que des fichiers XML.
Je suis en train de voir s'il y a des grandes différences au niveau de la lecture.

Citation:

---

Envoyé par DEV-10

C'est une bonne idée en soi, sauf que pour les champs à ajouter, comment tu pense les insérer dans le fichier excel pour chaque client afin qu'ils soient lus par l'application ? on parle d'une dizaine d'item à ajouter mais pour des milliers de répondants.

---

Pour ajouter dans des fichiers csv il n'y a pas de problème, par contre pour les "vrais" fichiers excel l'utilisation d'une API Microsoft est "obligatoire" il me semble.


L'important c'était la différence qu'il y avait entre écrire les informations à garder pour chaque client dans le code (après mise à jour du fichier contenant ce code il faut faire plusieurs manipulations avant que ce soit utilisable) et dans un fichier XML (lu dynamiquement par l'application, après modification de ce fichier XML, plus rien d'autre à faire).

Citation:

---

Envoyé par goomazio

Pour ajouter dans des fichiers csv il n'y a pas de problème, par contre pour les "vrais" fichiers excel l'utilisation d'une API Microsoft est "obligatoire" il me semble.


L'important c'était la différence qu'il y avait entre écrire les informations à garder pour chaque client dans le code (après mise à jour du fichier contenant ce code il faut faire plusieurs manipulations avant que ce soit utilisable) et dans un fichier XML (lu dynamiquement par l'application, après modification de ce fichier XML, plus rien d'autre à faire).

---

As tu plus de détails sur la solution XML ?

Citation:

---

Envoyé par DEV-10

As tu plus de détails sur la solution XML ?

---

Non. Après ce n'est plus de l'analyse, je ne m'aventure pas plus loin... Pas besoin de plus de détails, ce que j'ai dis ça fait déjà beaucoup. On pourrait m'avoir dit "ça va j'ai compris" déjà dix fois, je pense...

Mais si tu as des questions précises n'hésite pas à demander bien sur.