Thierry Andriamirado escreveu:
It seems that once SqliteReturnString <> SQLITE_OK for a dataset, all
the TSQLite3Datasets in the app loose their synchs with the SQLite3
engine.
In case of conflict, for example when editing data in a dbGrid, if an
'unique' constraint causes SqliteReturnString <> SQLITE_OK :
Editing in the TDbGrid does not call the sqlite database, so
SqlitereturnString has no meaning.
SqliteReturnString only has a meaning after calling ExecSql, Open,
CreateTable etc functions.
TSqliteDataset does not handle unique, not null constraints of all
fields automatically. The programmer must do yourself using OnValidate
event.
The only exception is AutoInc field which is ensured to be a primary key.
* the DBGrid keep the edited line as if it was ok, and let you continue
adding other data lines
* if you continue working with -another- TSQLite3Dataset and tables
(same database), ApplyUpdates don't work anymore.
The solution I found is to close and re-open the first dataset (the one
which initiated the problem) just after testing SqliteReturnString.
(lazarus 0.9.14-1 and fpc-2.0.2-0)
oh, and SqliteReturnString need to be trimed when tested, his length
when := 'SQLITE_OK' is 19.
Try the fpc svn version of sqlite3ds or the one found at
http://www.geocities.com/camara_luiz/sqlite4fpc/index.html. It has more
verbose messages among other improvements.
Luiz
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
