2010-05-12 4 views
1

J'ai écrit une application qui permet à un utilisateur de créer et exécuter une requête, puis enregistrer le rapport dans un fichier. Ils peuvent charger le rapport à partir d'un fichier à une date ultérieure et afficher à l'écran.Delphi TADOQuery SaveToFile problème

J'utilise un composant TADOQuery pour exécuter la requête et j'appelle SaveToFile lorsque la requête a renvoyé des données. J'utilise ensuite LoadFromFile pour charger les données dans un TADOQuery et à partir de là, je peux lire les données dans une liste virtuelle. Dans les deux cas, je spécifie "pfXML" comme paramètre de format.

Un utilisateur a signalé un problème selon lequel l'un des champs du rapport affiche des données parasites au lieu d'un texte lisible. Lors de l'analyse, la définition du champ dans leur document xml pour ce champ particulier est spécifiée comme "dt: type = 'bin.hex'". Lorsque j'exécute la même requête sur un système ici, la définition de champ dans mon document XML est spécifiée comme "dt: type = 'string'".

Ma question est donc pourquoi y a-t-il une différence? Les bases de données sont identiques, alors pourquoi les données sont-elles enregistrées sous bin.hex sur le système de l'utilisateur et sous forme de chaîne sur tous les autres? Peut-être plus au point, comment le type de données est-il déterminé? Lorsque j'appelle SaveToFile, comment le composant TADOQuery connaît-il le type de données et ce qu'il doit écrire dans le document xml comme type de données? Est-ce que les données sont renvoyées au PC au format hexadécimal, et que le composant TADOQuery s'en inspire, ou pense-t-il (pour une raison quelconque) que le type de données pour ce champ est hexadécimal? cela change les données en conséquence?

Je ne trouve rien en ligne à ce sujet et je ne sais pas ce qui se passe, donc toute aide serait appréciée.

Répondre

0

Il semble que cela a quelque chose à voir avec la façon dont le serveur est configuré. Nous n'avons rencontré le problème que sur un site client et sur une version très ancienne de OS400 (les requêtes sont exécutées sur des bases de données DB2).

0

À première vue, sonne comme un encodage unicode/char.

Questions connexes