Discussion :

[Aka Guymelef]

Bonjour,

j'ai actuellement un soucis. J'ai une procédure stockée qui me ramène un flux XML de la sorte : SELECT * FROM TABLE FOR XML EXPLICIT (je suis sous SQL Server 2005). Le flux XML à la sortie est valide pas de problème.

Par contre je voudrais savoir comment faire pour récupérer ce flux XML en utilisant un composant TADOStoredProc. En effet j'ai bien essayé de la manière classique en récupérant le RecordSet puis en faisant Fields[0].AsString mais je n'ai pas le résultat attendu, juste 'D'. Je me doute que pour ce cas là il doit y avoir une manipulation un peu particulière mais je n'ai pas réussit à trouver laquelle.

Aussi si quelqu'un sait comment faire et pourrez me poster un exemple ce serait extrêmement sympa.

Merci d'avance.

[Aka Guymelef]

Bon alors j'ai un peu avancé sur mon problème en castant le seul champ retourné en tant que TBlobField et j'ai extrait le contenu avec un TMemoStream.

J'arrive à obtenir une chaîne mais le format est des plus bizarre et me fait penser que le flux renvoyé est dans un format propriétaire ou quelque chose comme ça.

J'arrive à voir quelques caractères qui correspondrait bien à mon flux mais le reste de la chaîne n'est pas formé correctement. Je ne peux stocker cette chaîne que dans un WideString ce qui supposerait que c'est un encodage unicode mais je ne suis pas parvenu à trouver un jeu de caractère permettant de décoder parfaitement la chaîne.

Quelqu'un en sait-il plus sur ça ?

[Aka Guymelef]

Bon alors après analyse j'ai pu trouver une cause probable à mon soucis. Le postula de départ étant que j'arrivais pourtant à le faire sous VB mais passé avec le TADOStoredProc je n'y arrivais pas. En fait j'ai découvert qu'il s'agissait d'un problème de version de ADO.

En effet VB utilisait la librairie 2.7 tandis que Delphi7 utilise la version 2.1 (unité ADOInt.pas). En regardant un peu plus profondément j'ai pu détecter que l'alias _Command sous la version 2.1 encapsule un Command15 tandis que ce même alias sous la version 2.7 encapsule un Commande25. Je suppose donc que la différence vient de là.

[Franck SORIANO]

Oui, ça vient probablement de là.
Si je me souviens bien, il faut un ADO 2.5 ou 2.6 minimum (je ne sais plus quelle version exactement) pour pouvoir recupérer les flux XML de SQL Server.

Je pense que ADOExpress de D7 ne doit pas être capable de récuperer le flux XML.

Si tu utilisais ADO en VB, l'utilisation directe d'ADO (en utilisant les objets COM et pas l'encapsulation de Borland) ne doit pas te poser de problème.

Pour ce cas précis, tu devrais appeler les objets COM directement. Au besoin, importe la TLB au lieu d'utiliser ADOInt.pas.

[Aka Guymelef]

Merci de ta réponse, c'est sûrement ainsi que je vais procéder en créant une petite classe pour faire ça, mais c'est pas une priorité pour le moment. Quand ce sera fait je la mettrais pour les autres utilisateurs de D7.

Par contre du coup j'imagine que les versions supérieures à D7 doivent prendre en compte cette fonctionnalité ?

[Franck SORIANO]

Par contre du coup j'imagine que les versions supérieures à D7 doivent prendre en compte cette fonctionnalité ?

Je n'en sais rien, mais je ne parierais pas la dessus. J'utilise BDS2006. ADOInt.pas correspond toujours à ADO 2.1

Je ne crois pas qu'ADO et les fonctionnalités spécifiques à SQL Server soient une priorité pour CodeGear. Ils misent tout sur dbExpress et BDP.NET.

A mon avis, ce n'est pas prêt de changer.

Personnellement, lorsque j'utilise ADO c'est toujours directement à partir de la TLB.