Discussion :

[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.

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).

[DEV-10]

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)

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.

[goomazio]

É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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

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

et dans l'application on écrirait

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
 POUR Chaque Client
       Recherche dans le fichier XML les champs à ajouter
       Ajout des champs à ajouter
 FIN POUR

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...

[DEV-10]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[The eye]

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?

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?

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

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.

[The eye]

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

[DEV-10]

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.

[SaumonAgile]

Bon si on en revenait au problème ?

[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 ?

[DEV-10]

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.

[DEV-10]

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[DEV-10]

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.

[DEV-10]

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 ?

[DEV-10]

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)

[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.

[DEV-10]

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.

[goomazio]

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).

[DEV-10]

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 ?

[goomazio]

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.