Discussion :

[Nono23]

Bonjour tout le monde, J'ai un problème que je ne comprends pas très bien.

Mon application utilise actuellement des BDD Paradox pour gérer les tables temporaires. Je doit étudier un moyen de changer ce système par des tables SQLite.

Je dois réaliser une connexion depuis Delphi à une BDD SQLite via un alias ODBC. J'ai donc téléchargé un driver ODBC pour SQLite (http://www.ch-werner.de/sqliteodbc/) et connecté ma base de données via un composant wwQuery (Composant IPAccess du même type que TQuery).

J'ai également essayé avec les composants delphi UNIDac pour une connexion directe, sans passer par l'ODBC.

Jusque là, pas de problème, j'arrive à accéder à mes données avec les deux systèmes.

Mon problème arrive au moment d'accéder à la table système SQLITE_MASTER.

pour la même requête :

SELECT * FROM SQLITE_MASTER

je n'obtiens pas le même résultat :

La connexion UNIDac me retourne toutes les colonnes de la table MASTER, soit :
- Type
- Name
- Tbl_name
- RootPage
- SQL

La connexion ODBC via wwQuery ne me retourne que la colonne RootPage. J'ai également remarqué que des query telles que

PRAGMA table_info(NomDeMaTable)

Ne fonctionne qu'avec UniDac.
Est-ce que quelqu'un connaît la raison de ce problème? Est-ce normal?

Je sais que je pourrait utiliser UniDac, mais ça signifie changer la totalité de mes composants BDD. Cette opération sera réalisée à l'avenir mais dans un premier temps, j'aimerais simplement garder mes composants pour me connecter à SQLite de la même manière que je le faisait précédemment avec des tables Paradox.

Merci d'avance

[ShaiLeTroll]

Si ta volumétrie n'est pas énorme, tu peux tenter du ClientDataSet pour du stockage mais pas pour des Stats

Maintenant, SQLite est assez problématique sur les Dates, c'est important de le savoir !

En plus, SQLite contient des types pas trop standard SQL, ce qui doit ne pas plaire à ODBC (ou surtout à IP), UniDac n'est pas si éloigné du TQuery ou TADOQuery, par contre, je n'ai jamais testé les compos DB d'InfoPower en dehors du wwDBRichEdit pour ReportBuilder, mais cela ne doit pas être trop différent non plus !
Dans un petit programme test TQuery et TADOQuery, tu verras si c'est mieux que TwwQuery

Perso, j'utilise aussi MyDac pour MySQL, et l'on a aussi l'idée de vouloir étendre à PostGreSQL ou Oracle via UniDAC pour faciliter la vente de notre produit ! On a regarde SQLite, vraiement trop limité (sur problèmatique du ALTER)

[Nono23]

Hello ShailLeTroll.

Merci de ta réponse.

Après quelques recherches supplémentaires, il apparaît que j'ai même des problèmes avec mes tables standard et pas uniquement avec les tables système. Le problème semble venir des données de type VARCHAR. En effet, dans un gestionnaire de BDD que j'utilise et qui se connecte via ODBC, si j'affiche la structure de mes tables, le type des champs définis en VARCHAR sous SQLITE sont notés "unknown" et c'est précisément ces champs qui sont inaccessibles depuis Delphi et IPAccess.

ça me paraît assez bizzare étant donné que VARCHAR semble être un type assez standard.

J'utilise SQLite uniquement comme table temporaires sur les postes clients. les toutes les données de l'application sont stockées sous SQLServeur ou Firebird sur un serveur de données. La limitation de SQLite n'est donc pas un problème dans ce cas

Je vais essayer avec un TQuery standard et voir ce que ça donne.

[Nono23]

J'ai trouvé le problème. Dans la configuration de mon alias ODBC, je dois cocher la case NoWCHAR.
De cette manière, les types VARCHAR sont interprétés comme des String par l'ODBC et non plus comme des types UNKNOWN.

Par contre, La requête

PRAGMA table_info(TEST)

ne passe toujours pas, mais bon je peux me débrouiller sans donc ça ira