IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

SQLite Discussion :

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


Sujet :

SQLite

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre averti
    Profil pro
    Inscrit en
    Août 2008
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Août 2008
    Messages : 12
    Par défaut 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.

  2. #2
    Membre expérimenté

    Inscrit en
    Décembre 2004
    Messages
    169
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 169
    Par défaut
    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+

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    Août 2008
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Août 2008
    Messages : 12
    Par défaut
    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.

  4. #4
    Membre expérimenté

    Inscrit en
    Décembre 2004
    Messages
    169
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 169
    Par défaut
    Citation Envoyé par nicocomumumu Voir le message
    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 Voir le message
    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 Voir le message
    >> 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+

  5. #5
    Membre averti
    Profil pro
    Inscrit en
    Août 2008
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Août 2008
    Messages : 12
    Par défaut
    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 ? ) 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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 !

  6. #6
    Membre expérimenté

    Inscrit en
    Décembre 2004
    Messages
    169
    Détails du profil
    Informations forums :
    Inscription : Décembre 2004
    Messages : 169
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    commandes = new ArrayList<Commande>();
    on devrait avoir un id correspondant à l'objet "commandes" d'initialisé.
    Ensuite, pour une instruction
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    commandes.ADD(new Commande("produit 1", 100, 101));
    on crée une ligne du genre
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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+

  7. #7
    Membre averti
    Profil pro
    Inscrit en
    Août 2008
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Août 2008
    Messages : 12
    Par défaut
    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+

Discussions similaires

  1. Réponses: 0
    Dernier message: 07/04/2008, 17h56
  2. ajout d'une description pour des fichiers listes avec apache
    Par deny dans le forum Applications et environnements graphiques
    Réponses: 1
    Dernier message: 31/10/2007, 10h16
  3. Réponses: 1
    Dernier message: 03/07/2007, 13h12
  4. [code]Recherche d'une chaine dans des fichiers
    Par guillaume_pays_ceven dans le forum Contribuez
    Réponses: 5
    Dernier message: 21/06/2007, 14h32
  5. [MySQL] Comparer le resultat d'une requete avec des fichiers
    Par Anakior dans le forum PHP & Base de données
    Réponses: 2
    Dernier message: 20/12/2005, 11h11

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo