From a7af9af47ee98126f048bc9ccdada43c89ebfd1d Mon Sep 17 00:00:00 2001
From: r-zakarya <82443831+r-zakarya@users.noreply.github.com>
Date: Wed, 16 Sep 2026 23:15:42 +0100
Subject: [PATCH] fix(build): lier SQLite dans l'exe, qui chargeait sqlite3.dll
 du PATH
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Sans FireDAC.Phys.SQLiteWrapper.Stat, FireDAC charge sqlite3.dll au
demarrage. Sur ce poste ca marchait quand meme : le dossier bin
d'Embarcadero, qui en contient un, est dans le PATH. Sur une machine
sans Delphi, l'exe refusait de demarrer.

C'est le Win64 qui l'a revele — la DLL du PATH est 32 bits — mais le
Win32 livre etait casse de la meme facon chez quiconque n'a pas Delphi,
paquet prepare pour un tiers compris.

Prouve avec un PATH reduit a Windows : avec l'unite SQLite s'ouvre
(3.42.0), sans elle l'erreur exacte. Lire la table d'import ne
suffisait pas, le chargement est dynamique.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 CLAUDE.md                             | 14 ++++++++++++++
 delphi-backend/Source/PM.Database.pas |  6 ++++++
 2 files changed, 20 insertions(+)

diff --git a/CLAUDE.md b/CLAUDE.md
index 87f5c48..8b0264d 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -1435,6 +1435,20 @@ le vide ET vide `FPendingURL` → écran noir permanent sur cold-start lent.
   sources TMS. L'exe de `E:\password manager\` cree **son propre `vault.db`** a
   cote de lui, sans `config.txt` : ni le coffre de `delphi-backend\`, ni celui
   de `E:\a pmanager\`.
+- **SQLite doit etre LIE dans l'exe : `FireDAC.Phys.SQLiteWrapper.Stat` dans
+  `PM.Database`.** Sans cette unite, FireDAC **charge `sqlite3.dll`** au
+  demarrage. Le piege : **sur un poste de developpement ca marche quand meme**,
+  parce que `…\Embarcadero\Studio\23.0\bin\sqlite3.dll` est dans le PATH. On
+  croit donc livrer un exe autonome ; sur une machine sans Delphi il refuse de
+  demarrer (`[FireDAC][Phys][SQLite]-314 Cannot load vendor library`). C'est
+  le Win64 qui l'a revele — la DLL du PATH est 32 bits, donc introuvable pour
+  lui — mais le **Win32 livre jusqu'au 2026-09-16 etait casse de la meme facon**
+  chez quiconque n'a pas Delphi, y compris le paquet prepare pour un tiers.
+  Prouve avec un PATH reduit a `C:\Windows\System32;C:\Windows` : avec l'unite
+  « SQLite OUVERT 3.42.0 », sans elle l'erreur exacte. `Stat` et non `FDEStat` :
+  le coffre est un SQLite ordinaire, le chiffrement se fait cote JavaScript.
+  **Pour verifier qu'un exe est vraiment autonome, retirer Delphi du PATH** —
+  lire la table d'import ne suffit pas, le chargement est dynamique.
 - **Win64 (active le 2026-09-16).** Le groupe `Base_Win64` du `.dproj` etait
   quasi vide : **ni prefixes d'unites** (`Winapi;System.Win;…`), d'ou
   `F2613 Unite 'Windows' non trouvee` en recompilant TMS, **ni `Cfg_1_Win64`**
diff --git a/delphi-backend/Source/PM.Database.pas b/delphi-backend/Source/PM.Database.pas
index 8bb0cec..dd109b7 100644
--- a/delphi-backend/Source/PM.Database.pas
+++ b/delphi-backend/Source/PM.Database.pas
@@ -14,6 +14,12 @@ uses
   System.SysUtils, System.Classes, System.IOUtils, System.SyncObjs,
   FireDAC.Comp.Client, FireDAC.Stan.Def, FireDAC.Stan.Async,
   FireDAC.Phys.SQLite, FireDAC.DApt, FireDAC.Stan.Param,
+  // SQLITE LIE DANS L'EXE, SUR TOUTES LES PLATEFORMES. En Win32 FireDAC le
+  // faisait deja par defaut ; en Win64 il cherchait sqlite3.dll a cote de
+  // l'exe et refusait de demarrer. On ne livre qu'un exe, sans DLL : cette
+  // unite est ce qui le permet en 64 bits. Stat et non FDEStat — le coffre
+  // est un SQLite ordinaire, le chiffrement se fait cote JavaScript.
+  FireDAC.Phys.SQLiteWrapper.Stat,
   FireDAC.FMXUI.Wait, FireDAC.Stan.Intf, FireDAC.UI.Intf,
   Data.DB;