Roberto Padovani wrote:
Now, about assumptions.
in sqlite3ds there is the assumption that BOOLEAN fields are stored as
1 or 0. In fact, to recover a db that had "TRUE" and "FALSE", I made a
new class where I changed ftBool to fString. In this way I could read
them, parse them and then write them back as 1 or 0.
With the dates, the problem is similar, because sqlite3ds understands
that the field is of type "DATE", and so it makes the following
assumption in customsqliteds.pas line 603:
ftFloat,ftDateTime,ftTime,ftDate,ftCurrency:
begin
Val(StrPas(FieldRow),Double(Buffer^),ValError);
Result:= ValError = 0;
end;
True. It stores both in memory and in database the Double value.
In the database I have, the dates are in the ISO standard form
"2007-12-03 12:11:10.1234"
How do you suggest me to handle with them ?
1) by complicating the SQL queries with SELECT date(field_name) as
field_name FROM... which turns the field_name into a string in the
result set
Possible
2) by subclassing or anyway changing the TFieldType ?
Difficult
3) like with boolean, by making a special temporary class that parses
the whole database (not so big) and changes the dates into
Freepascal-style doubles (are they stored more efficiently ?)
I already started such tool. Not ready yet. Good if is one step eg you
won't access that file every time.
4) other (please specify :-))
Modify the sqlite3ds or create a TSqlite3Dataset descendant that:
1) Recognize a TIMESTAMP field
2) Stores the field value as a string in the desired format
3) When the data is loaded convert from string to double
4) When do ApplyUpdates convert from Double to String
I can do that.
My brain-storming last night came up with the idea of adding a flag
that says "force every field as a string": this would let someone who
doesn't know which convention was used in which field to inspect it.
Is it somewhat crazy ?
It's more difficult than above, but possible.
By the way, I really like sqlite and the unit you made to access it.
Good
When the project I'm working on is finished, I'll strip everything
from the source code and only leave a detailed tutorial for using
sqlite without visual components.
Good.
Meanwhile, I read somewhere in the
mailing that you are writing a documentation for sqlite3ds; is it
ready or partially ready ?
Partially ready. This is really needed because there's a lot of
undocumented features and some feature misuses (like using QuickQuery
for execute a SQL)
I'll be busy until 15/12. After that i will work on a solution for this
case, finish the documentation, work in improvements in sqliteds and
release a new sqlite3 wrapper.
I'll contact you.
I'm studying the whole code at the moment and some documentation would
help a lot, especially to see the global structure, to get the large
picture of it. Moreover, I'm going to keep on working a lot with
sqlite, so if some contribution is needed somewhere, let me know.
Fine. The documentation is a place that needs work.
Luiz
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
