Questions relatives aux bases de données SQLite (FireDAC)

De RAD Studio
Aller à : navigation, rechercher

Remonter à FAQ (FireDAC)

Cette rubrique contient une liste des questions et réponses relatives aux bases de données SQLite.

Q1 : Comment puis-je définir une séquence de classement dans une base de données SQLite ?

R : Consultez "FireDAC\Samples\DBMS Specific\SQLite\UserCollation" pour trouver des classements, fonctions, extensions, API et démos terminés.

Si vous avez besoin de classements/fonctions à la conception, construisez un package de conception ("simili" composant) là où vous recensez les classements/fonctions des utilisateurs.

Q2 : Exception SQLite "[FireDAC][DApt]-401. Enregistrement verrouillé par un autre utilisateur"

R : Cette exception est déclenchée avec la commande UPDATE, quand une connexion à une autre base de données a un curseur sur la même table et que tous les enregistrements ne sont pas extraits à partir de cette base de données. Vous devez utiliser FetchOptions.Mode=fmAll. Vous pouvez définir cette option au niveau ADConnection pour que tous les ensembles de données qui y sont liés héritent de cette option.

Q3 : Le type de données de l'élément de liste SELECT n'appartenant pas à une table est incorrect (ou) Ma fonction agrégée renvoie une valeur chaîne. Quel est le problème ?

R : SQLite ne renvoie pas un type de données pour les éléments de liste SELECT n'appartenant pas à une table. Si un élément est une expression, FireDAC ne peut pas récupérer son type de données. Il le décrit seulement comme ftWideString. FireDAC a la possibilité de spécifier le type de données de l'élément SELECT : <élément> sous forme "<alias>::<type de données>". Par exemple :

 SELECT count(*) as "cnt::int" from ...

Q4 : Il semble que les macros caractères ne soient pas supportées avec SQLite. J'ai essayé avec CONCAT, LEFT, SUBSTR, UCASE

R : Ces fonctions sont implémentées à l'aide de l'évaluateur d'expression de FireDAC. Quand vous créez une connexion à l'exécution, vous devez inclure uADStanExprFuncs.pas dans la clause uses.

SQLite a un ensemble limité de fonctions intégrées, mais il permet d'écrire et de recenser des fonctions personnalisées. FireDAC a de nombreuses fonctions personnalisées implémentées pour l'évaluateur d'expression. Leurs implémentations et recensements se trouvent dans FireDAC.Stan.ExprFuncs. Le pilote SQLite recense automatiquement toutes les fonctions connues de l'évaluateur d'expression avec sqlite3.dll.

Q5 : sqlite3_progress_handler est-il implémenté avec FireDAC ?

R : Oui. Utilisez un code semblable à :

 procedure Tform1.FormCreate(Sender: TObject);
 begin
   FDConnection1.Open;
   with TSQLiteDatabase(FDConnection1.ConnectionIntf.CliObj) do
   begin
     ProgressNOpers := 50000;
     OnProgress := SQLiteOnProgress;
   end;
 end;
 
 procedure Tform1.SQLiteOnProgress(ADB: TSQLiteDatabase; var ACancel: Boolean);
 begin
   Application.ProcessMessages;
 end;

Q6 : Les fichiers WAL deviennent très volumineux (> 1 Go) quand nous utilisons notre application multithread. Avez-vous des suggestions pour empêcher la taille des fichiers WAL d'augmenter ?

R : Si la taille des fichiers WAL continue à augmenter, cela signifie qu'il est impossible de déplacer des données depuis le journal vers le fichier de la base de données. La base de données est probablement utilisée en permanence par les opérations de lecture des threads et/ou les opérations DML sont effectuées sans valider une transaction. Dans ce cas, la solution consiste à utiliser uniquement des transactions brèves ou à créer un thread distinct pour les opérations DML (dans ce cas, les transactions doivent aussi être constamment validées).

Si un point de contrôle exécute et copie toutes les données WAL dans le fichier de la base de données, le rédacteur suivant recommence à écrire au début du fichier WAL. Le fichier WAL n'est généralement pas tronqué ici (voir PRAGMA journal_size_limit si vous voulez qu'il le soit). Ceci est dû au fait qu'il est plus rapide d'écraser un fichier existant que d'en tronquer un puis de l'ajouter.

Par conséquent, si tout se passe bien, SQLite doit revenir au début du fichier WAL après chaque point de contrôle, empêchant ainsi la taille du fichier WAL d'augmenter indéfiniment. Deux problèmes peuvent se produire :

  • Un lecteur peut empêcher un pointeur de contrôle de copier toutes les données du fichier WAL dans le fichier de la base de données, ou
  • Quand le point de contrôle est en cours, un autre processus peut écrire dans la base de données (ajouter des données au fichier WAL).

Si l'un des problèmes ci-dessus se produit, le rédacteur suivant ajoute des données au fichier WAL au lieu d'écrire au début de ce fichier. Si cela se produit pour chaque point de contrôle, la taille du fichier WAL augmente sans limite.