Discussion :

[Luc84]

Bonjour,

j'ai commencé à vévelopper sous C++ Rad Studio XE.
J'ai créé une base de données Firebird avec 1 seule table contenant des champs de type VARCHAR, de type INTEGER et un champ de type FLOAT.
Je crée une application sous Rad Studio XE (sous Windows seven) qui présente le contenu de la table dans un DBGrid : ok tout fonctionne.

J'installe l'application et la base de données sur un poste avec Windows XP.
A l'ouverture de la table, j'ai un message d'erreur "Operation not applicable".
Dans ma table, je transforme le champ de type FLOAT en type INTEGER.
Je relance, c'est ok.

Je travaille avec le même serveur de base de donnée sur les 2 postes : Firebird V 2.1.5.
J'utilise les composants DbExpress de Rad Studio.

Merci de votre aide.

[LinuxUser]

Je pense que tu as posté au mauvais endroit, je ne vois pas en quoi c'est un problème lié au C++.

[Luc84]

Tout simplement parce que j'ai porté une application développée sous Borland developer 2006 vers Rad Studio XE.
J'utilise le même serveur de base de données et la même base de données.
L'application portée sous Rad Studio XE tourne sous Windows Seven.
La même application avec sa base de données, installée sous Windows XP me génère l'erreur "Operation not applicable" dès que je veut ouvrir une table comportant un champ de type "FLOAT".

J'ai donc créé une application minimaliste et une base de données avec une seule table pour trouver mon problème. C'est ce cas là que j'ai mentionné dans mon premier post.

Je me demande si mon problème ne vient pas des composants DbExpress de Borland.

Si quelqu'un a rencontré des problèmes avec ces composants, je suis preneur.

[jblecanard]

Hello

L'explication m'a l'air simple : les composants DbExpress déployés sur la machine XP sont plus vieux que ceux de l'autre machine sous Seven, et ils ne supportent pas encore les type "FLOAT" ou alors c'est un dev de chez eux qui a mal déployé un UUID dans COM.

Bref, quelle que soit la raison exacte, peut-être faudrait-il envisager de migrer vers un code plus portable basé sur les standards classiques. Faire dépendre une application d'un IDE n'est jamais très bon.

[Luc84]

Bonjour, et merci pour la réponse,

L'explication m'a l'air simple : les composants DbExpress déployés sur la machine XP sont plus vieux que ceux de l'autre machine sous Seven, et ils ne supportent pas encore les type "FLOAT"

Je n'ai pas très bien compris l'explication "simple", vu que :
- mon application développée avec Borland developer 2006, tourne sous XP avec la même base de données Firebird (qui comporte des champs FLOAT),
- mon application portée vers Rad Studio XE, tourne sous Seven avec la même base de données Firebird (qui comporte toujours des champs FLOAT).
- cette application (Rad Studio XE) lancée sous XP génère une erreur lors de la lecture d'une table comportant des champs FLOAT. En transformant ces champs en DOUBLE PRECISION, plus de problème !

ou alors c'est un dev de chez eux qui a mal déployé un UUID dans COM

- mon exécutable est autonome, il n'y a pas d'installation à proprement parler, juste une copie de fichiers.

Bref, quelle que soit la raison exacte, peut-être faudrait-il envisager de migrer vers un code plus portable basé sur les standards classiques. Faire dépendre une application d'un IDE n'est jamais très bon.

A quoi penses-tu pour remplacer les composants dbExpress de Borland ?

Encore merci.

[jblecanard]

- cette application (Rad Studio XE) lancée sous XP génère une erreur lors de la lecture d'une table comportant des champs FLOAT. En transformant ces champs en DOUBLE PRECISION, plus de problème !

Tu avais dit que tu supprimais ces champs, pas que tu les transformais en DOUBLE PRECISION

- mon exécutable est autonome, il n'y a pas d'installation à proprement parler, juste une copie de fichiers.

Ton exécutable utilise des DLL déjà présentes sur le système, je doute fort que tu embarques la totalité du code exécuté, ou bien il serait énorme !

Lorsque tu crées ton exécutable, il inclue à l'intérieur une partie du code dont il a besoin mais une autre partie reste confiée aux bibliothèques déjà présentes sur la machine cible. Ne serais-ce que les API de base de Windows.

A quoi penses-tu pour remplacer les composants dbExpress de Borland ?.

SQLite, ou bien un truc nosql du genre leveldb. Malheureusement, ça risque de te coûter cher autant en apprentissage qu'en développement , c'était plus une décision à prendre au début du dev que maintenant.

D'une manière plus générale, ton problème est spécifique à Rad Studio XE, et peu de personnes sur ce forum pourront t'aider là dessus. Il vaut mieux t'orienter vers une communauté qui connaît bien cet IDE. Si tu as une licence, tu devrais contacter le support.