Luca Olivetti wrote:
En/na Luiz Americo Pereira Camara ha escrit:
- ApplyUpdates error handling: Error is handled just does not follows
the exception model. Check if ApplyUpdates is false. If so check
ReturnCode (see sqlite docs for values) and ReturnString values.
I understand and appreciate the KISS concept, but that's not the
behaviour I would expect from a dataset descendant.
Your approach is good enough only when you're controlling completely
data access in code (which is most of the times, but not always, the
correct thing to do), if you just want to write a quick'n'dirty data
entry application where you just wire up a datasource with, e.g., a db
grid and let the tool kit take care of the rest, with the exception
model the user at least get a meaningful error message, with your
implementation of ApplyUpdates the error is silently ignored and the
data is still visible on the dbgrid.
And even if you check the result of ApplyUpdates, if there are more
than 400 changes and the error only occurs in the first transaction I
think it will be silently ignored.
This is a flaw and will be fixed.
Raising an exception would not help here since the data would still be
there (in the grid).
- Primary key handling: sqliteds automatically handles primary key in
two ways. First add a AutoInc field to the table (Using
FieldDefs.Add/CreateTable) and sqliteds will ensure it will always be
unique and not null without user intervention. Second, if you have a
integer field as primary key set AutoIncrementKey to true and
PrimaryKey to the field name.
Ok, I didn't set AutoIncrementKey to true. Now I tried it and the
result is that I cannot edit the key in the dbgrid, I suppose that if
I want to allow manual insertion of a primary case I have to manage
that by myself.
Another test I did, is to leave AutoIncrementKey to false and try to
deliberately insert a duplicate of the primary key. Even if I check
the result of ApplyUpdates and use it to display a message, the
"wrong" rows are still visible in the dbgrid, then subsequent updates
succeed (without writing the data, since the dataset forgot about the
changes) and the wrong data is still visible in the grid. Ok, I can
refetch the
Just call Delete in AfterPost. Or in TField.OnChange change the field
value to one that you want or call Cancel (the last is not sure if will
work).
data in case of errors, but that's not really KISS anymore.
You must agree that you are not following KISS philosophy in your
program (maybe a requirement). How it is cover the most common user
cases and let the corner cases to the developer creativity.
See as a balance between features/code size.
Anyway, for more featured, you can use ZeosLib which is by far the most
complete database layer in fpc or even SqlitePass that has more options.
Luiz
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
