Adaptation de SQLite à une source différente des fichiers .db

Version imprimable

31/03/2009, 00h30
nicocomumumu

Adaptation de SQLite à une source différente des fichiers .db

Bonsoir,

Dans le cadre d'un projet d'envergure, je cherche à réutiliser SQLite et le driver ODBC trouvable en version BSD sur internet afin d'accéder des données depuis un requêteur de type Excel/Access.

Jusqu'ici rien d'anormal :). Le point sur lequel cela se complique est le suivant :

La source de données que je cherche à accéder diffère du mode de stockage utilisé par SQLite (fichiers .db), en effet, mes données sont présentes au sein d'une application qui tourne en "tache de fond" et à laquelle je prévois d'accéder via un système de socket TCP.

>> Ainsi, j'ai réussi à recompiler la biliothèque SQLite et son driver ODBC et je souhaiterais maintenant connaître précisément comment et où la librairie SQLite réalise l'interprétation de la requête SQL pour récupérer les données au sein des fichiers .db !

J'ai pu analyser en large et en travers les fichiers source ... mais je reste un peu perdu dans le volume de code ...

Pouvez-vous m'aguiller sur la méthode mise en oeuvre par SQLite et les fonctions sources associées ?

Merci pour votre aide.
31/03/2009, 20h55
bigane

Bonsoir,

Ta question est ardue, difficile de te dire comment et où sans rentrer dans le code, et mon temps est compté.
Cependant, voici quelques pistes qui vont dégrossir la voie.

1) Le moteur reçoit une chaîne sql avec par exemple sqlite3_prepare ou sqlite3_prepare_v2. C'est donc cette fonction que tu dois comprendre en premier.

2) Le moteur analyse le sql et le transforme en pseudo-code. Il y a donc un moteur d'analyse syntaxique et bien d'autres choses qui transforment un ordre sql en un petit programme. Si l'on a un ordre aussi simple que "select col from tab;", le moteur doit accepter la systaxe (fautes d'orthographe, parenthèses etc.), remplacer le select par une série d'instructions et enfin trouver col et tab dans le dictionnaire des de la base

3) En final, le moteur initialise le petit programme et renvoi ok. Il te reste à exécuter pas à pas l'ordre sql par sqlite3_step(). Cela aura pour effet de mettre en route l'interpréteur du pseudo-code et d'exécuter les instructions une à une jusqu'à la sortie d'une ligne de donnée ou la fin de l'ordre.

En analysant la fonction sqlite3_prepare tu pourras comprendre dans quelles fonctions le sql est décodé. Par contre je ne comprends pas ton besoin de le faire. En fait, le mode de stockage et la façon dont sqlite travaille en interne est (presque) sans importance pour ton objectif. Si tes données sont dans une autre base (exemple Access), tu peux déclarer ta base sqlite comme une source de données extérieure et mapper les tables de Sqlite dans Access. Ainsi, les tables SQLites sont considérées un peu comme des tables Access, et tu peux facilement lancer une requête Access du genre :
"insert into sqlite_matable select col1, col2 from matable2".
sqlite_matable étant une table sqlite liée à la base access, et matable2 une table ordinaire d'Access. A une époque, c'est comme cela que je reliais une table Oracle à une base Access.

Un pilote ODBC c'est justement une interface qui t'évite de "bidouiller" dans les sources des différents moteurs.

Voilà,
réponses un peu en vrac, mais cela pourra t'aider je pense.
a+
01/04/2009, 11h04
nicocomumumu

Bonjour,

Merci bien de toutes ces pistes, je vais regarder de près dans ces fonctions.

Tout à fait d'accord sur l'intérêt d'ODBC pour ces accès multiplateforme, la solution que j'explore et qui est d'adapter le fonctionnement d'SQLite est pour les raisons suivantes :

Je dispose d'une application Java qui manipule des listes d'objets. Les classes Java décrivant ces objets peuvent être vues comme la liste des attributs d'une table et l'instanciation d'objets de ces classes dans des listes peuvent être vues comme des n-uplets.

> Je dispose donc d'une sorte de petit SGBD basique en Java.

Mon but initial était alors de développer un driver ODBC permettant d'accéder ces données depuis un outil tel qu'Excel ou Access (pour réaliser un simple select avec quelques conditions, rien de plus). Seulement la difficulté d'un tel développement m'a amené à explorer d'autres solutions ....

>> Si toutefois vous avez de bons conseils sur ce point je suis preneur :)

En définitive, je me suis tourné vers SQLite pour pouvoir bénéficier de l'implémentation fonctionnelle de toute la partie "communication ODBC avec Access". J'espérais alors pouvoir bidouiller l'accès aux fichiers .db pour l'adapter à une communication de données de type XML/SOAP par exemple...

Si une solution meilleure est en votre connaissance, elle m'intéresse beaucoup ! :)

Merci bcp.
02/04/2009, 21h25
bigane

Citation:

Envoyé par nicocomumumu

Bonjour,

Merci bien de toutes ces pistes, je vais regarder de près dans ces fonctions.

C'est toujours utile de comprendre comment d'autres ont résolu les problèmes.

Citation:

Envoyé par nicocomumumu

Tout à fait d'accord sur l'intérêt d'ODBC pour ces accès multiplateforme, la solution que j'explore et qui est d'adapter le fonctionnement d'SQLite est pour les raisons suivantes :

Je dispose d'une application Java qui manipule des listes d'objets. Les classes Java décrivant ces objets peuvent être vues comme la liste des attributs d'une table et l'instanciation d'objets de ces classes dans des listes peuvent être vues comme des n-uplets.

> Je dispose donc d'une sorte de petit SGBD basique en Java.

Mon but initial était alors de développer un driver ODBC permettant d'accéder ces données depuis un outil tel qu'Excel ou Access (pour réaliser un simple select avec quelques conditions, rien de plus). Seulement la difficulté d'un tel développement m'a amené à explorer d'autres solutions ....

Oui, je pense que c'est une bonne résolution.
Non pas que ce serait du temps perdu, mais il y a de fortes chances que le résultat ne soit pas à la hauteur du temps dépensé pour le trouver.

Citation:

Envoyé par nicocomumumu

>> Si toutefois vous avez de bons conseils sur ce point je suis preneur :)

En définitive, je me suis tourné vers SQLite pour pouvoir bénéficier de l'implémentation fonctionnelle de toute la partie "communication ODBC avec Access". J'espérais alors pouvoir bidouiller l'accès aux fichiers .db pour l'adapter à une communication de données de type XML/SOAP par exemple...

Si une solution meilleure est en votre connaissance, elle m'intéresse beaucoup ! :)

Merci bcp.

Hum... Difficile de répondre car le but final de la demande est encore flou. Access étant une base de données, je ne vois pas l'intérêt d'y incorporer du fichier .db. sauf si ces fichiers sont sur un linux par exemple.
Pour un serveur SOAP java possède tout ce qu'il faut. SQLite ne serait qu'un fichier de données accédé depuis java, pas besoin d'Access : SQLiteJDBC en est un exemple http://zentus.com/sqlitejdbc/
Bref, je ne comprends pas l'intérêt de mélanger Java, SQLite et Access. Pour moi il y a un membre de trop dans cette équation.

Bonne poursuite,
a+

Après relecture de mon dernier post et de votre réponse, peut-être ai-je été un peu flou et pas assez synthétique.

L'utilisation de SQLite en combinaison avec Java et Access n'est qu'une piste (désespérée ? :roll:) que j'explore.

Je vais essayer de vous situer concrètement le projet (et clarifier le but final de ma demande) :

> Le programme Java est une contrainte. C'est lui qui contient les données sous forme de listes d'objets :
Code:

1 2 3 4 5 6 7 8 9 10 11 Class Commande{ String designation_produit; int quantite; int prix_total; } public static ArrayList<Commande> commandes; commandes = new ArrayList<Commande>(); commandes.add(new Commande("produit 1", 100, 101)); commandes.add(new Commande("produit 2", 200, 42));
Ce programme "tourne" en continu.

> Le but est de pouvoir accéder dynamiquement les données qu'il manipule et ce via Access (d'où l'intérêt d'ODBC comme solution).

Ce que j'avais espéré pouvoir exploiter d'SQLite dans tout ceci :

L'implémentation du standard ODBC (côté Access)
Adapter l'acces à un fichier .db pour le remplacer par un acces à l'application Java (via les sockets par exemple)

J'avoue que tout ceci est bien complexe ... et je vous remercie de votre intérêt ! :)

à bientôt !

Bonsoir,

Oui, la démarche peut paraître complexe mais elle me semble plus claire à présent : le but était d'interfacer Access et Java, l'interface étant constitué d'une base SQLite... Après réflexion je pense que c'est faisable. Un moment j'ai pensé utiliser une base de données sous forme de fichiers textes (csv) mais cette solution est trop statique. Je donne donc une piste pour SQLite :

1) depuis Java c'est "simple" d'utiliser un pilote pour SQLite. Je propose SQLiteJDBC (http://zentus.com/sqlitejdbc/ ) mais je ne le connais pas et il peut y avoir d'autres produits. Donc, lors de la création de l'instance d'une liste, on prépare une table d'une base SQLite. Puis lors des méthodes ADD, on recopie les données dans la table. Ainsi, pour les instructions

Code:

commandes = new ArrayList<Commande>();

on devrait avoir un id correspondant à l'objet "commandes" d'initialisé.
Ensuite, pour une instruction

Code:

commandes.ADD(new Commande("produit 1", 100, 101));

on crée une ligne du genre

Code:

insert into mesTraces values ("commandes","produit 1",100,101)

La structure de la table mesTraces pouvant également contenir un timestamp de création automatique, un autre de mise à jour ... bref une collection d'éléments permettant de suivre l'information.
Jusque là, tout est réalisable. On peut faire quelques tâtonnements ou une implémentation partielle de l'idée afin de ne pas perdre son temps sur une solution inutilisable. Je ne peux guère donner plus d'information, je ne travaille pas avec Java et je n'ai pas le temps de créer un environnement d'essai pour valider le concept... désolé. Mais je vais me rattraper avec VBA (Access).

2) On teste le résultat. En effet, on peut très bien se connecter sous DOS, Windows ou Linux à cette base, en lire le contenu, en faire une copie... bref des tests qui ne coûtent rien.

3) Si l'alimentation semble possible et que la lecture l'est également, on attaque le côté Access. On installe un pilote ODBC sur le poste Windows ( http://www.ch-werner.de/sqliteodbc/ ). Je n'ai pas Access, mais j'ai installé Outlook 2003 pour tester le principe en VBA. Je crée une base d'essais :
Code:

1 2 3 4 5 6 7 8 C:\>sqlite3 mabase.db SQLite version 3.6.12 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> create table mesTraces ( objname text, produit text, quantite number, prix number); sqlite> INSERT INTO mesTraces VALUES ("commandes","produit 1",100,101); sqlite> .exit
Depuis le panneau de configuration, je trouve les outils d'administration et je sélectionne "Sources de données (ODBC)". Dans "Sources de données système", je modifie la source "SQLite3 Datasource" qui s'est créée en installant le pilote ODBC de Werner. Je fais donc pointer cette source sur mon fichier "C:\mabase.db". Hop, je valide, c'est prêt.
Depuis Outlook, j'ouvre un nouveau module dans les macros (VBA). Dans "Outils / Références", je sélectionne "Microsoft DAO 3.6 Object Library" : ce composant me permet de lire et d'écrire dans une base Access sans posséder le logiciel, mais également de tester une connexion ODBC !

Dernier petit code :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Option Explicit Public Sub essai() Dim db As DAO.Database Dim rs As DAO.Recordset Dim strConnect As String strConnect = "ODBC;DSN=SQLite3 Datasource;" Set db = OpenDatabase("SQLite3 Datasource", False, False, strConnect) ' Information sur la connexion : Debug.Print db.Connect Set rs = db.OpenRecordset("select produit from mesTraces", dbOpenDynaset, dbReadOnly) Do While Not rs.EOF Debug.Print rs.Fields(0).Value rs.MoveNext Loop rs.Close db.Close Set rs = Nothing Set db = Nothing End Sub
Et voilà le travail, on arrive à lire la table "mesTraces" depuis Outlook 2003, et on peut le faire de la même façon depuis un quelconque produit Office 97 à 2003. Pour les versions supérieures, désolé... j'ai laissé tombé MsOffice pour OpenOffice. Mais ce devrait être pareil.

Courage,
a+

09/04/2009, 11h55
nicocomumumu
Bonjour,

Oui, merci beaucoup pour cette solution d'une base SQLite (.db) intermédiaire !
J'avais en effet réfléchi à cette solution en procédant quasiment de la même manière que vous :
- Côté Access :
  Utilisation du driver ODBC de SQLite (le même que celui que vous proposez)
- Côté Java :
  Utilisation de JDBC également.
  J'ai employé le patron de conception "observer" pour associer les créations/insertions dans les listes Java aux actions sur le fichier .db.
>> Cette solution constitue donc quelque chose de fonctionnel (je l'ai implémentée pour la gestion d'une table).

Mais ce n'est qu'un compromis vis-à-vis de l'objectif : se passer du fichier .db intermédiaire pour que, considérant l'application Java en train de "tourner", on puisse attaquer directement l'application Java sous Access via le driver ODBC SQLite.

>> D'où ma volonté d'adaptation du code source de la bibliothèque SQLite au niveau de l'accès aux fichier db.

J'avais envisagé une solution lors du traitement d'une requête SQL par la bibliothèque :
1) Au sein de la biliothèque SQLite J'avais envisagé de "détourner" la requête SQL reçue pour la transmettre telle quelle (sous forme textuelle) au programme Java.

2) Celui-ci se chargerait alors de la parser (des modules Java se chargeant de cela sont dispo sur sourceforge)

3) Le programme Java se charge de cibler les données recherchées par la requête.

4) ces données sont retransmises à la bibliothèque SQLite
=> Mais c'est ici que je perds tout espoir, vu l'incompatibilité qu'il y aurait entre les données transmises par Java à SQLite et le format compris par SQLite. :?

Merci encore de votre temps,
A+