oups...j'avais pas lu.....désolé

Si on veut faire encore plus simple et que le but est uniquement de savoir si une hôte répond au ping, on peut faire (en VB.net) My.Computer.Network.Ping("127.0.0.1")

La chaine de connexion ne passe pas chez moi....par contre, j'utilise "Driver={FileMaker Pro};server=MyServer;trusted_connection=yes,database=FMPLocal" et ça passe.

Le 2ème truc, c'est qu'a la première exécution, il y a une erreur (path not found) surement parce qu'il n'y a pas de dossier SQL dans le zip je l'ai créé et je test. ça à l'air de passer.

Le 3ème bug est la gestion des dates...En fonction de la localisation et des params régionaux. Tu split sur "/" dans mon PC les dates sont stockée sous le format "xx.xx.xxxx" (les joies des params régionaux).

Les rubriques multivaluée ne sont pas traitée en entier (seul la 1ère valeur est prise).
D'ailleur, si qqun sait comment faire pour récup. toutes les valeur d'une rubrique multivaluée, je suis preneur. Je cherche depuis un certain temps...

Pour finir, le résultat est erroné. Certains champs sont vides sur le txt alors qu'il y a quelque chose sur la base fp5. (je ne cherche pas ce que c'est car je voulais juste voir si les multivalué étaient pris en compte et ce n'est pas le cas...)


A+ et bon dév.

Je ne suis pas tant d'accord avec toi... Le but étant de montré une autre forme de case que celle que tu présente.
De plus, pour obtenir une explication plus complète du case, il te suffit d'ouvrir l'aide de transact SQL qui t'expliquera en detail le case avec 1 exemple. Mais qui ne montrera pas d'exemple de case comme celui que j'ai mis. Mon but n'étant pas de recopier l'aide d'SQL Server, J'ai pensé utile de mettre un code n'étant pas en exemple.

white_mage();

Si vous pensez que cette source peut nuire, n'heistez surtout pas à l'enlever.
En effet, j'ai longement réfléchi avant de mettre ce bout de source. Pour finir, j'ai décider de la mettre mais je ne sais toujours pas si c'est très utile.
J'espèrais surtout générer une prisede conscience de la part des developpeurs.

La meilleures methode pour ne pas risquer quelque chose est de ne pas avoir de faille de SQL injection. Si on prend le temps de verifier tous son code on peut éviter cela.

Une autre technique, est d'utiliser un utilisateur qui n'a pas le droit de création d'une table (ou qui n'a pas le droit d'insert). Cette methode est vraiment discutable car en effet, la requête ci-dessus ne fonctionnera pas, mais si un utilisateur peut injecter du code SQL, il peut de toute façon corrompre le serveur.

Les faille de SQL injection sont très très très grâve sur un site ou une application.

Un audit intensif des logs + du code + la création d'un utilisateur avec les droits minimums permettent déjà d'empêcher un massacre.

Alors à  vos sources ;-)