Ma requête SQL DELETE ne fonctionne pas

Bonjour,

Dans mon programme, j'interroge ma base de données avec des requêtes de type SELECT. Jusque là tout va bien.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

// Initialisation de la base de données IHM_FenetrePrincipale.IHM_DbSqliteConnection.DatabaseName:= DB_FileName; IHM_FenetrePrincipale.IHM_DbSqliteConnection.Connected := True; IHM_FenetrePrincipale.IHM_DbSqliteQuery.SQL.Clear; // Requete sql pour obtenir tous les Noms IHM_FenetrePrincipale.IHM_DbSqliteQuery.SQL.Add('SELECT DISTINCT "Nom" FROM table ORDER BY "Nom" ASC'); IHM_FenetrePrincipale.IHM_DbSqliteQuery.ExecSQL; IHM_FenetrePrincipale.IHM_DbSqliteQuery.Active:= true;   // Ajout des noms dans le chklistbox while not IHM_FenetrePrincipale.IHM_DbSqliteQuery.EOF do begin IHM_FenetrePrincipale.IHM_ChklistboxNom.Items.Add(IHM_FenetrePrincipale.IHM_DbSqliteQuery.FieldByName('Nom').AsString); IHM_FenetrePrincipale.IHM_DbSqliteQuery.Next; end;   // Fermeture de la base de données IHM_FenetrePrincipale.IHM_DbSqliteQuery.Close; IHM_FenetrePrincipale.IHM_DbSqliteConnection.Close;

---

Par contre, lorsque j'essaie de faire une requête de type DELETE, là je coince.
Je n'ai pas de message d'erreur et aucun enregistrement n'est effacé.
La requête que j'envoie fonctionne très bien avec SQLITEMAN

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

req := req + '"' + tag_checked[i] + '"'; // Initialisation de la base de données pour requete IHM_FenetrePrincipale.IHM_DbSqliteConnection.DatabaseName:= DB_FileName; IHM_FenetrePrincipale.IHM_DbSqliteConnection.Connected := True; IHM_FenetrePrincipale.IHM_DbSqliteQuery.SQL.Clear; // Execution de la requete IHM_FenetrePrincipale.IHM_DbSqliteQuery.SQL.Add(req); IHM_FenetrePrincipale.IHM_DbSqliteQuery.Prepare; ShowMessage(req); IHM_FenetrePrincipale.IHM_DbSqliteQuery.ExecSQL; // Fermeture de la base de données IHM_FenetrePrincipale.IHM_DbSqliteQuery.Close; IHM_FenetrePrincipale.IHM_DbSqliteConnection.Close;

---

Koa,

Vu ton code, ta requête est dans le brouillard :

Comment veux-tu qu'on sache ce qui résulte de

Code:

---

req := req + '"' + tag_checked[i] + '"';

---

Citation:

---

Envoyé par droggo

Comment veux-tu qu'on sache ce qui résulte de

Code:

---

req := req + '"' + tag_checked[i] + '"';

---

---

La requête que j'envoie fonctionne très bien avec SQLITEMAN
Oups, la requete que j'envoie ressemble à ceci :

Code:

---

DELETE FROM "tag" WHERE "Tag_name"="tintin"

---

Bonsoir,

Si "tintin" est une chaîne de caractères, ne devrait-il pas être encadré que de simples cotes. (doublées dans le texte en Pascal=>+'''' et non +'"')

André

En mode SELECT je passe ma requête avec les guillemets (")
Cela fonctionne impeccable. C'est pourquoi je me disait qu'en mode DELETE je pouvais aussi utiliser les guillemets.

J'ai quand même essayé ma requête DELETE les simples quotes comme vous me l'avez conseillé ; cela ne change rien.

Je ne sais pas si mon problème provient de ma requête DELETE (qui fonctionne quand je la passe en manuel dans SQLITEMAN) ou si j'ai oublié une instruction quelconque avant et/ou après EXECSQL.

NB : Lorsque je passe la requête DELETE avec les simples quotes dans SQLITEMAN, il me retourne REQUÊTE OK sans pour autant supprimer l'enregistrement. Et avec les guillemets, REQUETE OK avec la suppression de l'enregistrement. :mur:

Par désespoir, je regarde du coté des transactions.
Je suis complètement bloqué :cry:

Bonjour

Lorsque j'ai commencé a faire du dev SQL avec lazarus, je rajoutais moi aussi les double quote à la main, et très souvent mes requêtes n’aboutissaient pas.

C'est alors que la lumière m'est apparue dans un exemple avec la fonction QuotedStr() qui te retourne la chaine entourée de simple quote pour formater tes requêtes correctement :

Code:

---

req := req + QuotedStr(tag_checked[i]);

---

Ce qui au final donnerait

Code:

---

DELETE FROM tag WHERE tag_name='tintin'

---

sans les double quote autour des champs et nom de table

bon courage

si je comprends bien quand tu fait une requête SQL de type DELETE rien ne se passe. :scarymov:

Fait tu un ApplyUpdate après ton instruction DELETE ? :bug:

Ta base est SQLITE n'est ce pas ?

Lorsque je fait APPLYUPDATE juste après EXECSQL, il me retourne une erreur :
Operation cannot be performed on an inactive dataset.

C'est bien une base SQLITE3 que j'utilise.
La table ne contient que 1 colonne "Tag_name", sans index ni clé ni rien du tout. La colonne "Tag_name" est de type string.

Merci aussi pour l'astuce "QuotedStr".

Merci de votre aide je suis certain que mon problème va etre résolu.
Et que c'est juste un détail...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

uses Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, ComCtrls, StdCtrls, CheckLst, eventlog, sqlite3conn, sqldb, db, types;     req := req + QuotedStr(tag_checked[i]); // DELETE FROM tags WHERE Tag_name='Tintin' // Initialisation de la base de données pour requete IHM_FenetrePrincipale.IHM_DbSqliteConnection.DatabaseName:= DB_FileName; IHM_FenetrePrincipale.IHM_DbSqliteConnection.Connected := True; IHM_FenetrePrincipale.IHM_DbSqliteQuery.SQL.Clear; // Execution de la requete IHM_FenetrePrincipale.IHM_DbSqliteQuery.SQL.Add(req); ShowMessage(req); IHM_FenetrePrincipale.IHM_DbSqliteQuery.ExecSQL; IHM_FenetrePrincipale.IHM_DbSqliteQuery.ApplyUpdates; // Fermeture de la base de données IHM_FenetrePrincipale.IHM_DbSqliteQuery.Close; IHM_FenetrePrincipale.IHM_DbSqliteConnection.Close;

---

Citation:

---

Envoyé par ulysse_31

Lorsque je fait APPLYUPDATE juste après EXECSQL, il me retourne une erreur :
Operation cannot be performed on an inactive dataset.

---

Il faudrait que tu vérifie l'état de ton Dataset lors de ton ApplyUpdate. ta requete doit être certainement fermée avant.

Pour SQLITE3 j'utilise la Zeos Access 7.0 pour programmer.
Avec c'est bien plus simple, c'est multi environnement. (Delphi, C++ et autre)

Pour accéder à une table je pose une ZConnection, une ZTable et un datasource .

Avec Zeos access 7.O ta suppression ressemblerait à

Citation:

---

ZTable1.Delete;

---

et pis c'est tout... ;)

Donc, Dans ton cas plus besoin de

Citation:

---

DELETE FROM tag WHERE tag_name='tintin'

---

ni de :bug:

Citation:

---

'SELECT DISTINCT "Nom" FROM table ORDER BY "Nom" ASC'

---

Avec Zeos c'est plus simple.

Pour chercher une un record c'est par exemple

Citation:

---

if ZTable1.Locate(laCle, Ma valeur, Mes options)= true then ....;

---

Jazz

Bonjour,

Citation:

---

Envoyé par ulysse_31

C'est bien une base SQLITE3 que j'utilise.
La table ne contient que 1 colonne "Tag_name", sans index ni clé ni rien du tout. La colonne "Tag_name" est de type string.

---

Ok...
Je suppose que vous utilisez les composants de base fournis avec Lazarus à savoir : TSQLite3Connection, TSQLQuery et TSQLTransaction.
Mais, je ne vois pas de validation de transaction dans votre code....

En nettoyant un peu le tout, on devrait avoir :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

req := req + QuotedStr(tag_checked[i]); // DELETE FROM tags WHERE Tag_name='Tintin' // Initialisation de la base de données pour requete IHM_FenetrePrincipale.IHM_DbSqliteConnection.DatabaseName:= DB_FileName; // Ouverture de la base de données IHM_FenetrePrincipale.IHM_DbSqliteConnection.Connected := True; try // Préparation de la requête IHM_FenetrePrincipale.IHM_DbSqliteQuery.SQL.Clear; IHM_FenetrePrincipale.IHM_DbSqliteQuery.SQL.Add(req); ShowMessage(req); // Execution de la requete IHM_FenetrePrincipale.IHM_DbSqliteQuery.ExecSQL; // Validation de la transaction // Je suppose que le composant de transaction rattaché à celui de connexion // s'appelle IHM_DbTransaction et est de type TSQLTransaction IHM_FenetrePrincipale.IHM_DbTransaction.Commit; // "Fermeture" de la requête inutile car il ne s'agit pas d'une requête de sélection // IHM_FenetrePrincipale.IHM_DbSqliteQuery.Close; finally // Fermeture de la base de données IHM_FenetrePrincipale.IHM_DbSqliteConnection.Close; end;

---

Citation:

---

Envoyé par Ph. B.

Bonjour,
Ok...
Je suppose que vous utilisez les composants de base fournis avec Lazarus à savoir : TSQLite3Connection, TSQLQuery et TSQLTransaction.
Mais, je ne vois pas de validation de transaction dans votre code....

En nettoyant un peu le tout, on devrait avoir :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

req := req + QuotedStr(tag_checked[i]); // DELETE FROM tags WHERE Tag_name='Tintin' // Initialisation de la base de données pour requete IHM_FenetrePrincipale.IHM_DbSqliteConnection.DatabaseName:= DB_FileName; // Ouverture de la base de données IHM_FenetrePrincipale.IHM_DbSqliteConnection.Connected := True; try // Préparation de la requête IHM_FenetrePrincipale.IHM_DbSqliteQuery.SQL.Clear; IHM_FenetrePrincipale.IHM_DbSqliteQuery.SQL.Add(req); ShowMessage(req); // Execution de la requete IHM_FenetrePrincipale.IHM_DbSqliteQuery.ExecSQL; // Validation de la transaction // Je suppose que le composant de transaction rattaché à celui de connexion // s'appelle IHM_DbTransaction et est de type TSQLTransaction IHM_FenetrePrincipale.IHM_DbTransaction.Commit; // "Fermeture" de la requête inutile car il ne s'agit pas d'une requête de sélection // IHM_FenetrePrincipale.IHM_DbSqliteQuery.Close; finally // Fermeture de la base de données IHM_FenetrePrincipale.IHM_DbSqliteConnection.Close; end;

---

---

Bonsoir Philippe

Dans le cas d'Ulysse31, je ne vois pas l’intérêt de l'utilisation de transaction pour un seule table avec un seul champs ....

Jazz

@Jazz77 de mon point de vue ton utilisation des ZEOSDBO est incorrecte , certainement de vieux réflexe BDE qui trainent .
Ouvrir une table entière , surtout en lecture/écriture , chercher l'enregistrement pour le supprimer est très "consommateur" . L'utilisation d'un SQL pour supprimer un enregistrement est beaucoup plus rapide/efficace .
De plus ton "Table1.Delete;" n'efface que l'enregistrement en cours ! pas un ensemble .

N'oublions pas que par défaut également que les ZEOSDBO sont en autocommit par défaut


avec une TZReadOnlyQuery (ZROQ) posé sur une forme

Code:

---

1 2 3

ZROQ.SQL.Text:='DELETE FROM TAG WHERE TAG_NAME=:TN'; ZROQ.ParamByName('TN').asString:='tintin'; ZROQ.ExecSQL;

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

var ZROQ : TZReadonlyQuery; begin ZROQ:=TZReadOnlyQuery.Create(null); try ZROQ.Connection:=ZConnection1; ZROQ.SQL.Text:='DELETE FROM TAG WHERE TAG_NAME=:TN'; ZROQ.ParamByName('TN').asString:='tintin'; ZROQ.ExecSQL; finally ZROQ.Free; end;

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11

// simple Connection.ExecuteDirect('DELETE FROM TAG WHERE TAG_NAME='+QuotedStr('tintin')); // plus travaillée Connection.ExecuteDirect(Format('DELETE FROM TAG WHERE TAG_NAME=%s',[QuotedStr('tintin')])); // en raffinement on peut utiliser l'autre forme de ExecuteDirect pour obtenir le nombre de suppression var ns : integer; begin if Connection.ExecuteDirect(Format('DELETE FROM TAG WHERE TAG_NAME=%s',[QuotedStr('tintin')]),i) then Showmessage(Format('%d Suppression(s)',[i]) else Showmessage('je me suis planté');

---

Bonjour Serge,

Citation:

---

@Jazz77 de mon point de vue ton utilisation des ZEOSDBO est incorrecte , certainement de vieux réflexe BDE qui trainent .

---

Pour ma culture personnel, si tu pouvais développer ton argumentation, cela serait bien.

Citation:

---

Ouvrir une table entière , surtout en lecture/écriture , chercher l'enregistrement pour le supprimer est très "consommateur" . L'utilisation d'un SQL pour supprimer un enregistrement est beaucoup plus rapide/efficace .

---

En quoi chercher un enregistrement est il "consommateur" ?
Temps ? (combien de millisecondes en plus ?)
Mémoire ? combien d'Octets en plus ?

Je pense que l'on parle d'un base mono-poste en locale . Alors les performances temps d’accès et mémoire ne sont pas forcément déterminant...

Citation:

---

De plus ton "Table1.Delete;" n'efface que l'enregistrement en cours ! pas un ensemble .

---

Complétement d'accord avec toi.
Dans le cas d'ulysse31 il n'est pas mentionné de supprimer un ensemble d'enregistrements.

Jazz

Bonjour Jazz77,

Citation:

---

Envoyé par Jazz77

Dans le cas d'Ulysse31, je ne vois pas l’intérêt de l'utilisation de transaction pour un seule table avec un seul champs ....

---

C'est assez inquiétant ce que vous dites là :roll:, même pour une table avec une seule colonne. Les transactions sont un des fondements de tout SGBD qui se respecte : A quoi servent les transactions ?
D'autre part, le composant TSQLQuery ne peut se passer d'un composant TSQLTransaction.
Mais bon vaut mieux un petit exemple qu'un long discours. Prenez la base et la table décrite par Ulysse31, créez une application Lazarus avec les composants adéquats, un composant TButton pour tester le code suivant, une fois avec l'instruction désactivée, une fois sans : ;)

Code:

---

1 2 3 4 5 6 7 8 9 10 11

procedure TForm1.Button1Click(Sender: TObject); begin SQLite3Connection1.Connected := True; try SQLQuery1.SQL.Text := 'DELETE FROM TAG WHERE TAG_NAME = ' + QuotedStr('tintin'); SQLQuery1.ExecSQL; //SQLTransaction1.Commit; finally SQLite3Connection1.Connected := False; end; end;

---

Et surveillez le contenu de la table TAG depuis Sqlite Manager...

Citation:

---

Envoyé par Ph. B.

Bonjour Jazz77,C'est assez inquiétant ce que vous dites là :roll:, même pour une table avec une seule colonne. Les transactions sont un des fondements de tout SGBD qui se respecte :

---

Si mes souvenirs sont exacts, les transactions sont faite pour conserver l'intégrité d'un Base. Elle permettent dans le cas d'erreur de revenir à état stable à un instant T-1.
Je ne remets pas cela en question bien évidement. C'est indispensable dans le cas d'opérations complexes ou en environnement mufti utilisateur.

Mais la dans ce cas sur une base locale mono utilisateur sur une seule table et un seule enregistrement, ce n'est pas forcément utile de monopoliser des trésors de complexité et un florilège de code ;)

J'ai toujours entendu qu'il fallait éviter de complexifier du code inutilement et qu'il faut faire simple quand cela est préférable.

Dans ce cas, à mes yeux un simple ZTable1.delete suffit et Zeos et Sqlite sait le faire très bien. Et il n'y a aucune inquiétude à avoir..

Jazz

Citation:

---

Envoyé par Jazz77

Si mes souvenirs sont exacts, les transactions sont faite pour conserver l'intégrité d'un Base. Elle permettent dans le cas d'erreur de revenir à état stable à un instant T-1.
Je ne remets pas cela en question bien évidement. C'est indispensable dans le cas d'opérations complexes ou en environnement mufti utilisateur.

---

Vision trop restreinte de la problématique.
Je cite Frédéric Brouard qui définit les transactions :

Citation:

---

Les transactions sont la clef même de toute problématique d'accès concurrent. Même lors de simples lectures, le SGBDR doit pouvoir assurer le respect de la cohérence des données dans le temps. Bien entendu, lors de modifications de données, les transactions servent à garantir que tout soit mené à bien sans qu'il en résulte la moindre anomalie, ou à l'inverse, si une anomalie se produit, de revenir à l'état antérieur, c'est à dire l'état qu'avaient les données avant le démarrage de la transaction.

---

Au cas où vous l'auriez oublié, un accès concurrent peut se faire au sein d'une même application et ce même en lecture;

Citation:

---

Envoyé par Jazz77

Mais la dans ce cas sur une base locale mono utilisateur sur une seule table et un seule enregistrement, ce n'est pas forcément utile de monopoliser des trésors de complexité et un florilège de code ;)

---

d'autre part, je connais beaucoup d'utilisateurs qui vont lancer 2 fois une même application soi disant monoposte...

Citation:

---

Envoyé par Jazz77

J'ai toujours entendu qu'il fallait éviter de complexifier du code inutilement et qu'il faut faire simple quand cela est préférable.

---

Vous avez raison, aussi vaut-il mieux une instruction "DELETE FROM" transactionnée à plusieurs opérations "Locate", "Delete" qui elles même vont générer de multiples accès à la base de données, voire de multiples transactions !

Citation:

---

Envoyé par Jazz77

Dans ce cas, à mes yeux un simple ZTable1.delete suffit et Zeos et Sqlite sait le faire très bien. Et il n'y a aucune inquiétude à avoir..

---

Comme l'a dit @SergioMaster, il s'agit d'une approche BDE du temps des bases de données orientées fichiers (paradox pour ne pas le citer), et pas de l'approche que l'on doit avoir pour lire et écrire les données d'une base, même en mono-utilisateur.

Citation:

---

Envoyé par Ph. B.

Vision trop restreinte de la problématique.
Je cite Frédéric Brouard qui définit les transactions :

Au cas où vous l'auriez oublié, un accès concurrent peut se faire au sein d'une même application et ce même en lecture;
d'autre part, je connais beaucoup d'utilisateurs qui vont lancer 2 fois une même application soi disant monoposte...


Vous avez raison, aussi vaut-il mieux une instruction "DELETE FROM" transactionnée à plusieurs opérations "Locate", "Delete" qui elles même vont générer de multiples accès à la base de données, voire de multiples transactions !

Comme l'a dit @SergioMaster, il s'agit d'une approche BDE du temps des bases de données orientées fichiers (paradox pour ne pas le citer), et pas de l'approche que l'on doit avoir pour lire et écrire les données d'une base, même en mono-utilisateur.

---

Sauf que dans votre raisonnement, vous oubliez que les applications orientés "Fichiers" marchaient plutôt pas mal même.


Quelque soit l'approche orienté "Fichiers" ou SGBD, si une application est robuste, bien documenté et maintenable facilement, c'est l'essentiel.

Bien sur qu'un accès concurrent peut se faire sur en locale.
Cela se gère.
On peut aussi écrire une application mono instance bien écrite , cela se fait bien aussi. 8-)

Je suis d'accord qu'un "DELETE FROM" est bien plus efficace que plusieurs locate, delete, mais cela n'a jamais été mon propos ici ;)

Jazz

Dans mon post , je ne prenais pas en compte une approche mono-poste .
De toute façon une approche multi-utilisateur (voire réseau) même dans le cas d'une application monoposte n'est pas moins robuste .
Autant prendre de bonnes habitudes :roll:

Citation:

---

Envoyé par Jazz77

Sauf que dans votre raisonnement, vous oubliez que les applications orientés "Fichiers" marchaient plutôt pas mal même.

---

Ben voyons, mais au prix d'un florilège de codes (je vous cite) !

Par analogie, les avions commerciaux à moteurs à piston marchaient plutôt pas mal aussi, mais ces derniers ont été remplacés par des turbines ou des turbo-réacteurs dont la fiabilité et les performances sont bien supérieures... ;)

Citation:

---

Envoyé par Jazz77

Quelque soit l'approche orienté "Fichiers" ou SGBD, si une application est robuste, bien documenté et maintenable facilement, c'est l'essentiel.

---

Et si elle est écrite en tenant compte du fonctionnement de ses différents éléments dont le moteur de base de données, c'est encore mieux...

Citation:

---

Envoyé par Jazz77

Bien sur qu'un accès concurrent peut se faire sur en locale.
Cela se gère.

---

Donc vous vous contredisez, plutôt que laisser faire le SGBD, vous préférez complexifier le code de l'application cliente pour aboutir au même résultat.

Citation:

---

Envoyé par Jazz77

On peut aussi écrire une application mono instance bien écrite , cela se fait bien aussi. 8-)

---

Ca, c'est affectivement côté applicatif.

Citation:

---

Envoyé par Jazz77

Je suis d'accord qu'un "DELETE FROM" est bien plus efficace que plusieurs locate, delete, mais cela n'a jamais été mon propos ici ;)

---

Vous avez quand même prétendu le contraire précédemment, en préférant un ZTable1.Locate() et un ZTable1.Delete !
De plus, utiliser une table plutôt qu'une requête est contre-performant en temps (même s'il s'agit de millisecondes) comme en ressources : il faut ouvrir la table (= rapatrier les lignes de cette table auprès de l'application), parcourir ces lignes, supprimer un enregistrement (= notifier la base de données)...
Comme l'a rappelé @SergioMaster, autant prendre de bonnes habitudes, même pour une application mono-poste mono-instance, car qui dit qu'elle n'évoluera pas vers du multi ?

Bonjour,

Le code ci-joint fonctionne chez moi sans problème.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

procedure TForm1.EffaceEnregistrement (NomTable : String ; ValCle : integer ) ; Var SQLQ_Tmp : TZQuery ; begin SQLQ_Tmp := TZQuery.Create(self); try SQLQ_Tmp.connection := ZConnection1 ;   SQLQ_Tmp.SQL.Clear; SQLQ_Tmp.SQL.add('delete from ' + NomTable + ' where num = ' + IntToStr(ValCle )) ; SQLQ_Tmp.ExecSQL; finally SQLQ_Tmp.Free; end; end;   procedure TForm1.Button2Click(Sender: TObject); begin   // carnet est le nom de la table SQLite, 5 est la valeur de la clé de l'enregistrement à supprimer EffaceEnregistrement ('carnet' , 5 ); ZTable1.Active:= false; ZTable1.Active := true ; // rafaichissement de l'affichage   end;

---

J'ai lu dans le fil que ta base n'est pas indexée, ce genre de blocage, j'ai déjà eu et cela m'avait couté quelques heures de travail. :aie:
Essaye en créant une clé primaire.

Bonjour

je cite le Lazarus Database Tutorial

Citation:

---

par Luiz Américo

Aller sur la page d'accueil sqlite pour plus d'information .
Introduction

TSqliteDataset et TSqlite3Dataset sont des descendants de TDataset qui accède , respectivement , aux bases de données sqlite version 2.8.x et 3.2.x. Ci-dessous une liste des principaux avantages et inconvénients :

Avantages :

Flexible : les programmeurs peuvent choisir d'employer ou de ne pas employer la langue de SQL , leur permettant de travailler avec les dispositions simples de table ou n'importe quelle disposition complexe que SQL/sqlite permet
Mise à jour automatique de la base de données : aucun besoin de mettre à jour manuellement la base de données avec des instructions SQL, une méthode simple s'occupe de ça
Rapide : il cache les données en mémoire, rendant la navigation dans le jeux de données rapide
Aucune installation/configuration de serveur : just ship together with sqlite dynamic library

---

Pour l'instant les "Pro" des SGBD (je pense surtout à Philippe), je n'ai pas vu une ligne de code sécurisé dans vos exemples 8-) (mise à part l'exemple n°3 de code de Sergio)

Qu'est ce vous faites en cas d'accès concurrent ? sur un problème d'un simple DELETE ? apportez vos lumières......

Je n'ai pas vu une seule ligne de code concernant cela ?

Éclairez ma lanterne, Je ne demande qu'a voir la lumière et la lire le code des "Pro" :mrgreen: (surtout Philippe)

Jazz

Citation:

---

Envoyé par Jazz77

Pour l'instant les "Pro" des SGBD (je pense surtout à Philippe), je n'ai pas vu une ligne de code sécurisé dans vos exemples 8-) (mise à part l'exemple n°3 de code de Sergio)

---

Si vous n'avez pas compris qu'il est préférable d'envoyer une seule requête "DELETE ..." à un SGBD plutôt qu'ouvrir une table côté application, charger toutes ses lignes en mémoire (double emploi avec ce que fait Sqlite entre autres), les parcourir puis supprimer celles qui correspondront à vos critères (ce qui génère une commande supplémentaire auprès du SGBD), cela montre que vous ne connaissez pas le fonctionnement d'un SGBD et va à l'encontre de ce que vos propos antérieurs.

Citation:

---

Envoyé par Jazz77

J'ai toujours entendu qu'il fallait éviter de complexifier du code inutilement et qu'il faut faire simple quand cela est préférable.

---

Citation:

---

Envoyé par Jazz77

Qu'est ce vous faites en cas d'accès concurrent ? sur un problème d'un simple DELETE ? apportez vos lumières......

---

C'est là qu'interviennent les transactions et leur niveau d'isolation (du plus faible "lecture sale" ou "dirty-read" au plus élevé "sérialisé") et ce que vous faites dans les traitements transactionnés.

Citation:

---

Envoyé par Jazz77

Je n'ai pas vu une seule ligne de code concernant cela ?

---

Regardez mieux...

Citation:

---

Envoyé par Jazz77

Éclairez ma lanterne, Je ne demande qu'a voir la lumière et la lire le code des "Pro" :mrgreen: (surtout Philippe)

---

Encore faudrait-il que vous compreniez les bases du sujet... :zoubi:

Citation:

---

Envoyé par Ph. B.

Encore faudrait-il que vous compreniez les bases du sujet... :zoubi:

---

En gros Philippe ...... vous venez sur le forum, vous sortez votre pseudo savoir pour casser les autres ......

Cependant j'ai trouvé le fil de la discussion très intéressante .
Je n'avais peut être pas vu comme l'a souligné Sergio les utilisations possibles des bases locales sur tous les angles en cas de multiple session utilisateurs.

Je vais essayer de me documenter sur la bonne utilisation des SGBD.

Mais tant de code pour un simple delete, cela m'ennuie un peu quand même si c'est la seule solution.

Jazz :ccool:

Bonsoir,

Pour revenir calmement au sujet, j'utilise

• les transactions quand j'émets plusieurs requêtes liées. Par exemple, ajout d'une facture et de ses lignes. Si toutes les requêtes d'INSERT ou d'UPDATE nécessaires à l'enregistrement de la facture ne provoquent pas d'erreur, alors on "commite" sinon, on "roolbacke". Ainsi tout est écrit ou rien.
• les verrous de ligne quand c'est possible (OK en PostgreSQL, mySQL innoDB mais pas en mySQL MYISAM)... et en fonction des besoins

Evidemment si on bénéficie dans la base de la gestion des Doublons, des Contraintes... c'est un énorme plus dont il ne faut pas se priver.

Maintenant, la manière de développer avec Lazarus dépend des connecteurs utilisés, des bases utilisées... Par exemple jusqu'à la version 9.30, les connecteurs natifs manquaient de précision avec PostgreSQL. Ils constataient l'erreur mais n'étaient pas capables de fournir leur numéro... Lors d'une modification un refus pouvait être un Doublon ou un Blocage... ce qui obligeait à des contorsions pour savoir... Il faut s'adapter aux réalités des versions de Lazarus.

Enfin, il y a l'utilisation de la base. On peut gérer les accès concurrentiels de diverses manières de par la demande des utilisateurs... en coopératif, en exclusif... ou en force : c'est le dernier qui a raison :aie:

Dernier point, j'allais oublier : si cela n'a pas changé, SQLite n'est vraiment pas adapté pour faire de l'accès concurrentiel... et pour ne pas ouvrir 2 fois le même programme à partir d'un même poste http://wiki.freepascal.org/UniqueInstance/fr

En conclusion, je ne crois pas qu'il y ait une méthode générale à appliquer systématiquement. Il y a probablement une meilleure façon, c'est à dire mieux adaptée à la situation que l'on rencontre. Je me méfie énormément des lieux communs et j'apprécie tout autant les approches autodidactes , raisonnées et expérimentées : si je vous dis qu'en mySQL je n'utilisais pas les DataSource... et d'ailleurs pas non plus maintenant en PostgreSQL, que dbExpress m'a semblé inepte, que j'ai pris Zeos à la place, que j'ai abandonné pour les natifs en Lazarus et qu'en Delphi je n'hésiterais pas à choisir AnyDAc enfin FireDac* (jusqu'en février ce n'était pas le discours officiel)... Je peux expliquer mes choix à chaque fois même s'ils paraissent déroger à cette chère orthodoxie.

A bientôt. Gilles

PS : Je n'aime pas trop l'utilisation des QuotedStr. Je préfère (ce n'est pas supérieur, mais plus souple) :

Code:

---

1 2	req := 'INSERT INTO tags (Tag_name) VALUES (:paStr);'; Params.ParamByName('paStr').AsString := 'xxxx';

---

*c'est une excellente nouvelle et ouvre plein de perspectives...

Quelle discussion intéressante :ccool:

Citation:

---

Envoyé par Ph. B.

D'autre part, le composant TSQLQuery ne peut se passer d'un composant TSQLTransaction.

---

Désormais, et hormis les requêtes de type SELECT, j'encadrerais tous les autres types de requêtes par des transactions. Et le moins de quotes possible.

Requete SELECT (sans quotes) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

// Initialisation de la base de données IHM_FenetrePrincipale.IHM_DbSqliteConnection.DatabaseName:= DB_FileName; IHM_FenetrePrincipale.IHM_DbSqliteConnection.Connected := True; IHM_FenetrePrincipale.IHM_DbSqliteQuery.SQL.Clear; // Requete sql pour obtenir tous les plugins IHM_FenetrePrincipale.IHM_DbSqliteQuery.SQL.Add('SELECT DISTINCT Nom FROM plugins ORDER BY Nom ASC'); IHM_FenetrePrincipale.IHM_DbSqliteQuery.ExecSQL; IHM_FenetrePrincipale.IHM_DbSqliteQuery.Active:= true;   // Ajout des noms dans le cheklistbox while not IHM_FenetrePrincipale.IHM_DbSqliteQuery.EOF do begin IHM_FenetrePrincipale.IHM_ChklistboxNoms.Items.Add(IHM_FenetrePrincipale.IHM_DbSqliteQuery.FieldByName('Nom').AsString); IHM_FenetrePrincipale.IHM_DbSqliteQuery.Next; end;   // Fermeture de la base de données IHM_FenetrePrincipale.IHM_DbSqliteQuery.Close; IHM_FenetrePrincipale.IHM_DbSqliteConnection.Close;

---

Requête INSERT (et DELETE) (quotes obligatoires sinon elle passe pas !) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

// Ajout du tag dans la base de données tag req := 'INSERT INTO tags (Tag_name) VALUES (' + QuotedStr(str) + ')'; // Initialisation de la base de données pour requete IHM_FenetrePrincipale.IHM_DbSqliteConnection.DatabaseName:= DB_FileName; IHM_FenetrePrincipale.IHM_DbSqliteConnection.Connected := True; IHM_FenetrePrincipale.IHM_DbSqliteQuery.SQL.Clear; // Execution de la requete IHM_FenetrePrincipale.IHM_DbSqliteQuery.SQL.Add(req); IHM_FenetrePrincipale.IHM_DbSqliteQuery.ExecSQL; IHM_FenetrePrincipale.IHM_DbSqliteTransaction.Commit; // Fermeture de la base de données IHM_FenetrePrincipale.IHM_DbSqliteConnection.Close;

---

Sujet résolu encore merci la communauté :merci: