Discussion :

[mat.M]

Tant de mépris me laisse sans voix..

??? Là je crois que cela vire au dialogue de sourds :
encore une fois est-ce que j'ai parlé de mépris de quelque chose ????


Et j'ai posé des questions précises je suis en droit d'attendre des réponses précises merci

[Jedai]

Effectivement, dialogue de sourd...
Aussi je ne répondrais sans doute plus à tes messages, sauf si j'observe une évolution.
Pour la dernière fois, je te demande de relire sa demande et de réaliser enfin que sa demande n'est pas comme tu le crois un logiciel de gestion de contrat, mais uniquement une "moulinette" qui servira d'intermédiaire entre un logiciel probablement graphique (je m'avance un peu ici) qui sert à rédiger les contrats et qui a peut être été écrit en Clipper (ou en Swahili pour ce que j'en sais et ce que ça nous intéresse ici) et des bases de donnée et sites sur internet.

Par ailleurs, j'aimerais bien savoir pourquoi tu persistes à m'agresser sur le fait que je n'ai aucune expérience en entreprise (j'aimerais d'ailleurs bien savoir sur quoi tu te bases exactement), ce qui est vrai d'ailleurs, mais dont je ne vois pas en quoi cela me disqualifie d'office, d'autant que j'ai suffisamment d'ami qui ont cette expérience et que j'ai bien conscience des réalités d'entreprises. Ainsi, je croyais que nous étions ici sur Developper.com et non que j'étais en plein entretien d'embauche, aussi me suis-je permis d'exprimer mon opinion sur VBA, ce que je ne ferais évidemment pas en entretien, mais merci pour ta condescendance paternaliste qui t'a incité à me donner ce conseil totalement superflu et hors de propos.

Je ferais simplement une citation :

Perl même s'il n'est sans doute pas le meilleur langage pour concevoir une GUI

Ce que tu commentes par :

Perl est le meilleur language du monde de l'informatique , JAva est le meilleur....,C++ est le meilleur....
On peut faire tous les languages comme cela.

: :

J'ai également l'impression que "N'importe quoi !!" est ta réaction dès lors qu'on t'accuse de quelque chose, par exemple d'avoir une vision réductrice de Perl, je cite pourtant ces quelques lignes que n'importe quel utilisateur, même occasionnel de Perl saura apprécier à leur juste valeur :

PERL ce n'est pas un outil RAD comme Delphi ou VB avec des composants visuels.
PERL c'est bien en milieu universitaire ou de recherche comme le MIT de Boston ou je ne sais quoi mais pas pour une PME.
Perl c'est un language script seulement en ligne de commande.

--
Jedaï

[mat.M]

ok l'incident est clos

[FredBe]

Ok, ok, je crois qu'on a un peu dérappé dans le sujet ...

Je confirme : il n'est en aucun cas question de créer une application de gestion de contrats d'assurance ! On a un mainframe pour ça et même si c'est vieux, je ne connais rien de plus stable et de plus rapide (par contre, moins cher, je connais ).

Le coeur de ce que je dois mettre en place devra fonctionner comme un service sur un serveur Windows (ou aix si on est amenés à passer à la vitesse supérieure).

Des fichiers texte en pagaille ? Ben oui, ce sont tous des résultats d'extractions de notre mainframe que nous voulons exploiter dans des reporting plus complexes. Le seul problème, c'est que les outils de reporting mis en place chez nous nécessitent soit des tables SQL, soit des tables DBF comme fichiers source. D'où les conversions de fichiers txt en DBF ou SQL.

Aujourd'hui, chaque programme d'extraction à un nom de 8 caractères qui est connu par notre clipper. Quand on détache un fichier txt qui porte le nom d'un prg d'extraction, le clipper recherche un template DBF qui porte le même nom, le copie dans le répertoire où le fichier txt a été trouvé et importe le fichier txt dans le DBF vide.
Ensuite, tout est paramétrable :
_ le DBF est parfois utilisé tel quel
_ le DBF peut servir de table source à un report qui est déclenché par le même clipper qui a fait la conversion
_ le DBF peut être converti en table MySQL pour servir dans notre site internet (php + MySQL) où nos clients pourront consulter leurs stats, l'état de leurs contrats, ...

Je sais que je suis débutant, mais je doute très sérieusement de pouvoir faire ça en VBA

Cela dit, je ne suis toujours pas sûr et certain que Perl me sauvera, mais ce que je cherchais, c'étaient des pistes et c'est ce que j'ai obtenu ici.

Je concentre maintenant mes recherches en comparant Perl, Java et peut-être C++.

Merci à tous !

Fred.

[mat.M]

c'est que les outils de reporting mis en place chez nous nécessitent soit des tables SQL, soit des tables DBF comme fichiers source.

il est souhaitable par souci d'homogénéité d'avoir des tables de bases de donnée.
Attention les tables SQL n'existent pas SQL c'est un language pour créer des tables

D'où les conversions de fichiers txt en DBF ou SQL.

Tout le monde sera d'accord , vive PERL !

Je sais que je suis débutant, mais je doute très sérieusement de pouvoir faire ça en VBA

VBA c'est vaste et c'est un language intégré à Ms-Office ( Word , Excel , Access ) .C'est pas plutôt Visual Basic dont tu voulais parler ?

[FredBe]

En effet, SQL est un langage, mais à ma connaissance, je ne peux pas lancer de requête SQL sur une table DBF ... Si ? J'avais compris qu'il me fallait une DB SQL (ou MySQL dans ce cas précis).
Au lieu de remplir un DBF, je devrais alors créer une table dans MySQL et l'alimenter avec mes fichiers txt.

Pour VBA, le fait est que je ne voulais même pas en parler dans le cadre de ce projet : je ne l'ai cité que pour donner une idée de l'étendue (ou plutôt de la petitesse) de mes connaissances en développement. Pour une raison qui m'échappe, on a cru que je voulais m'en servir pour cette moulinette.

Pour ce qui est de PERL, au niveau du traîtement des fichiers txt, ça a effectivement l'air génial, mais est-ce qu'un langage qui n'est pas compilé ne risque pas de bouffer beaucoup de ressources si je le fais tourner comme un service ?

Fred.

[laffreuxthomas]

Bien moins que Java si tu l'utilises pour de la manipulation de fichiers textes. Sur mon vieux K6 350MHz je m'étais fait une moulinette qui ouvrait les 500 fichiers de mon projets, les scannait ligne par ligne pour changer des trucs, les ré-écrivais ..... 3 secondes de traitements. En Java ça en aurait pris plusieurs dizaine à mon avis.

[FredBe]

Voilà typiquement le genre d'exemple que j'attendais de trouver pour réfléchir à PERL plus sérieusement !

Merci !

[lunatix]

autant pour la facilité de traitement de chaines de caracteres y'a pas photo, autant pour les perfs je suis pas du tout persuadé que perl soit plus rapide que java (voir a mon avis c'est le contraire)

genre
http://www.google.fr/search?q=cache:...ient=firefox-a

ca vaut ce que ca vaut hein ! c'est pas la preuve ultime, mais ca montre bien que java peut tourner vite quand meme