Discussion :

[bubu42]

Bonjour,

J'essaie de mettre au point un petit programme permettant de gérer une base de données Sqlite3 avec 3 ou 4 postes sur un réseau. J'utilise le composant TSqlite3Dataset. D'après la documentation, l'accès à la base est impossible quand un poste est en train d'écrire (locked)
J'aimerais donc faire une routine (avec try...except, par exemple) qui teste l'état de la base avant une opération d'écriture et permette d'attendre que la base soit accessible, sans planter le programme, avant de lancer l'opération d'écriture.
Quelqu'un a-t-il une idée ?
D'avance, merci.

[Invité]

Bonjour,

Si vous êtes en version 3, il semble que cela soit gérer automatiquement : http://www.sqlite.org/lockingv3.html. Je n'ai pas vérifié. Je me suis simplement rappelé avoir lu cet article il y a quelques semaines alors que je testais les connecteurs natifs en SQLite.

Néanmoins, à mon avis, le "try except end;" est à conserver... ne serait-ce que pour gérer d'éventuelles tentatives d'INSERT ou d'UPDATE avec des doublons sur des clés uniques.

Cordialement. Gilles

[bubu42]

Merci de cette réponse.
J'avais aussi vu cet article, mais je crois qu'il ne concerne pas directement le TSqlite3Dataset. Ca doit être prévu pour un accès direct à l'aide de TSqlite3Connection, TSqlQuery ou TSqlTransaction...
Je vais donc bien laisser le try..except avec le TSqlite3Dataset.
Au passage, je n'arrive pas à utiliser correctement le TSqlite3Connection et ses associés. Et les tutoriaux ne sont pas légion dans ce domaine. Je crois que je vais démarrer un autre fil à ce sujet.

[Invité]

Bonjour,

De la documentation, vous pouvez en trouver sur le site de Chris : http://lazarus-fr.espace-malin.fr/in...nnees&Itemid=4
-----------
En ce qui concerne votre demande initiale, je suppose que les connecteurs et autres Datasets fonctionnent conformément aux spécifications du "moteur" de la base. Donc, l'article est probablement valable.
-----------
Maintenant en ce qui concerne les connecteurs natifs et plus spécifiquement SQLite, je peux vous renvoyer à une récente discussion http://www.developpez.net/forums/d96...natif-sqlite3/

Je dois avouer que j'ai (encore) du mal avec les connecteurs natifs. Je me perds entre les InsertSQL, UpdateSQL, DeleteSQL et SQL et d'autre part entre les ApplyUpdates, SQLExec... Plusieurs membres de ce forum ont essayé de m'expliquer... en vain. Ce qui ne signifie en rien que les composants natifs soient bugués ou mauvais* ... mais que je ne sais pas m'en servir correctement
-----------
Et ceci s'explique. Je fais un peu de publicité pour une solution alternative et free : Zeos. Facile à installer, de conception et d'utilisation plus simple (c'est un avis) et surtout plus polyvalente (c'est un fait) : avec un même jeu de composants, on peut "attaquer" de nombreuses bases sans réécrire son code (simplement les requêtes). Ainsi, je passe facilement de mySQL à postgreSQL (à éventuellement SQLite) avec exactement les mêmes composants et le même code... Et par exemple, en myISAM qui ne gère pas le transactionnel, je ne suis pas obligé de placer un SQLtransaction ... En plus pour les "Delphiens", ce composant existe aussi. C'est d'ailleurs, en cherchant une alternative au passage imposé par Borland à dbEXpress et sa toute aussi imposée "contorsion bidirectionnelle" que j'ai découvert cette suite. Adresse de téléchargement http://sourceforge.net/projects/zeoslib/

Installation : Dezipper ZEOSDBO-6.6.6-stable dans lazarus/components
Lancer Lazarus --> Paquet --> Ouvrir un fichier paquet(.lpk) --> ../lazarus/components/ZEOSDBO-6.6.6-stable/packages/lazarus/zcomponent.lpk -->Use... -->Installer
(Procédures identiques sous Windows et Linux.)

Une fois installé : 2 composants sont nécessaires Zconnection et ZQuery (au lieu de 3 pour SQLite3Connection, SQLTransaction, SQLQuery)... on branche alors le Datasource sur le Dataset (SQLQuery ou ZQuery) et ensuite la DBGrid par exemple sur le DataSource...
---
Je peux vous placer sur mon ftp un exemple qui fonctionne avec Zeos mais qui bloque pour une raison que j'arrive mal à déterminer avec les composants natifs mais qu'un spécialiste "natif" pourra certainement corriger. Exemple qui DROP, CREATE et rempli une table, affiche dans une DBGrid, Insert et Update.... mais il faut avoir installer ZeosLib pour l'utiliser ...

Cordialement. Gilles

*Les connecteurs natifs ont eu des problèmes mais il y a longtemps et une récente question à ce sujet est restée sans réponse ce qui semble montrer qu'ils ont été résolus

[Invité]

Bonjour,

J'ai testé pendant une bonne partie de la journée les connecteurs natifs et SQLite3... C'est vraiment galère. J'enlève le CR que j'avais commencé : j'ai rencontré tellement de problèmes que je crois que je vais fatiguer tout le monde...

Je m'associe donc à Bubu42 : une doc exhaustive, des exemples complets qui fonctionnent... cela serait intéressant.

Cependant, j'ai pu tenter de connecter 2 postes sur la base SQLite3 qui est placé sur un serveur Windows. Le programme lancé en premier de station de test a créé la table et l'a affichée dans un dbGrid.

Ensuite à partir de Lazarus installé sur mon poste de développement, j'obtiens ceci :


Donc, bien que je n'ai pas fait tous les tests, SQLite3, ce serait éventuellement du multi-user ?

• Si les 2 utilisateurs utilisent des tables différentes : cela fonctionnerait ? Moi, je n'obtiens pas cela. Le même programme, lancé des 2 postes, mais l'un créant une table T1 et l'autre une table T2, passe évidemment sur le premier mais affiche la même erreur sur le second. Le répertoire du fichier database.db est pourtant bien désigné comme partagé avec les droits nécessaires. Je suis peut-être passé encore à côté de quelque chose. Je vérifierai demain... Mais il est bien indiqué que c'est la database qui est locked et non la table comme l'indique la doc. Est-ce que la doc est erronée, est-ce que les connecteurs natifs ne permettent pas ce type de "partage" ?
  
• Mais même à supposer qu'on puisse ouvrir la base en même temps, si 2 utilisateurs veulent utiliser la même table, ce ne serait "possible" qu'alternativement si on en croit la doc de SQLite3. Et donc ceci aurait quand même une forte contrainte au niveau de la programmation : la table considérée ne pourrait pas être en connexion par exemple avec une dbGrid. Dès que le Dataset est Open, la table est verrouillée et donc l'autre utilisateur qui voudrait ne serait-ce qu'insérer un enregistrement dans cette même table, ne pourrait pas accéder à celle-ci. Evidemment, on pourrait contourner cette limite en chargeant la table dans une StringGrid... puis on coupant le DataSet...

Mais est-ce que cela en vaudrait la chandelle ?

Cordialement. Gilles

[Invité]

Bonjour,

Pour Bubu42,

j'ai réussi finalement à utiliser proprement -me semble-t-il- la suite native avec SQLite3. Je ferai un petit tuto dès que Chris aura vérifié mes codes, début septembre.

En attendant, j'ai comparé la Doc SQLite3 et les résultats que j'ai obtenu en multi-user avec la suite native de Lazarus.

En résumé : Dès que l'on veut écrire dans une table, la base entière (et non pas seulement la table) est verrouillée... quelque soit le cas de figure. Seule utilisation multi-user constatée : l'affichage dans une dbGrid de 2 tables différentes de manière concomitante sur les 2 postes de tests. En réalité, je n'attendais pas mieux. SQLite n'est pas (re)connue pour son utilisation multi-user. Mais, avec les SQL natifs, on est très loin des améliorations précisées dans la doc de SQLite3 notamment au niveau de la gestion "automatique" de ces accès.

Voici le détail des tests : http://www.selzig.com/1008261114/cr.pdf

Même si les résultats sont un peu décevants, je n'estime pas avoir perdu mon temps : j'ai pu me faire une opinion plus affirmée sur les connecteurs natifs. Cela semble fonctionner globalement correctement avec des particularités que j'ai parfois trouvées étonnantes mais la documentation les concernant est trop rare... Evidemment, avec SQLite, c'est un peu particulier. Il faudrait essayer sur postgreSQL (PQConnection) ou mySQL InnoDB pour se faire vraiment une idée (ou Oracle).

En attendant, je garde mes habitudes, c'est-à-dire Zeos avec mySQL et postgreSQL... sachant que Zeos n'est pas nécessairement la panacée. J'avais "dû" faire une première tentative SQL native car Zeos à l'époque 6.6.4 avec Lazarus 0.9.26 ne s'installait pas bien sur Mac OS X. Je ne sais pas si cela c'est amélioré depuis.

Petites précisions : j'ai rencontré un sérieux problème de lecture de la base dès que les champs contenaient des lettres accentuées ou des espaces. J'avais eu le même problème -autant que je me souvienne- avec SQL natif et mySQL. Cela doit se régler dans le SQLConnect. J'ai également testé les CommitRetaining qui ont pour particularité "d'affliger" une très grande lenteur aux opérations d'écritures avec ce moteur.

Cordialement. Gilles

[Invité]

Bonjour,

Vérification en Zeos : En Zeos (6.6.6), les spécifications telles qu'indiquées dans SQLite3 fonctionnent correctement.

Lorsqu'un enregistrement est en lecture, la table n'est pas verrouillée. D'autre part, je peux lancer l'insertion de 100 enregistrements simultanément sur 2 postes à condition que chaque Insertion soit individuellement placée dans un Transaction. C'est Zeos/SQLite qui gère l'ensemble (bloque la table) en 'faisant patienter' les opérations dans la file d'attente. Les temps de réponses sont tout à fait convaincants. On peut dans les mêmes conditions "Updater" et "Deleter".

Sur le petit programme de simulation que j'ai réalisé (cf image ci-dessous), en ouvrant 2 sessions Zeos (sur un poste ou sur plusieurs), cela fonctionne très bien (1 Zconnect+1ZQuery+1 ZupdateSQL). Maintenant, si je lance la Form SQL Native (une ou plusieurs Forms Zeos étant ouvertes), cela ne fonctionne plus...


Bref, SQLite3 + Zeos, c'est assez bluffant dans sa simplicité d'utilisation... mais évidemment cela reste limité puisque par exemple, on ne peut pas placer un verrou sur un enregistrement...

Donc Bubu42, à moins de travailler sous Mac (je ne sais pas si Zeos y est installable), si vous voulez utiliser des réseaux d'accès concurrentiels sur une table SQLite 3, à mon avis, il y a bien une solution. Pour la SQL native, pour conclure, on attendra l'avis autorisé de Chris sur la question après vérification de mes codes...

Cordialement. Gilles

[chris37]

Hello world

Même sans vérifier ton codes, il y a des lacunes trop profondes qui trainent depuis trop longtemps (cf mes derniers post du printemps ).

Je vais voir à monter un jeux de tests des que le temps me le permettra

Cordialement,
Chris

[Invité]

Bonjour,

A la rigueur, ce n'est pas grave car il y a une solution alternative aux connecteurs natifs.

D'un autre côté, plutôt que de les "améliorer", il serait peut-être plus utile de faire un travail de synthèse -codes à l'appui- des problèmes rencontrés. Puis on expédie cela à l'équipe de développement de Lazarus. Ce serait à mon avis plus efficace.

J'avais demandé, il y a quelques mois, si certains utilisateurs des composants natifs -dont je ne suis pas habituellement- rencontraient (encore) des problèmes. [http://www.developpez.net/forums/d93...cteurs-natifs/] Compte tenu de l'absence de réponses, on pouvait supposer qu'il y en avait peu. J'avais posé la même question, il y a 2 ans. A priori, à l'époque, la suite était considérée comme fonctionnelle. Je m'étais alors embarqué dans un projet... et m'étais "planté". Suite à la question posée par Bubu42, j'ai regardé à nouveau. Je ne dis pas que cela fonctionne pas... mais dans le cas de SQLite 3, pas comme annoncé par la doc (de SQLite 3) donc pas réellement "compatible"... Ceci dit, je n'utilise que mySQL et postgreSQL (et maintenant un peu SQLite 3) et donc ce n'est pas nécessairement représentatif... Les connecteurs natifs fonctionnent peut-être très correctement avec Oracle, InterBase...

Là, il faudrait peut-être, avec l'aide des participants à ce forum, recenser les problèmes rencontrés avec les connecteurs natifs pour être aussi exhaustif que possible, ensuite les classer et les regrouper -ce qui induit nécessairement une phase d'analyse- et enfin les hiérarchiser pour être aussi efficace que possible... et on transmet le résultat d'un travail collaboratif, pas trop ambitieux, ou chacun peut apporter utilement son expérience. Et ce type de travail collaboratif a de plus le mérite de faire progresser chacun.

Evidemment, je mets mes codes à disposition...

Cordialement. Gilles