You are not logged in.
Pages: 1
Hi,
first of all : thanks for your great job !
I'm trying to understand how it works....
I've two questions.
TRecordReference : perhaps a limit of 64 tables could be few for some projects. Could be used an int64 instead of a 32 bits reference ?
TTimelog is certainly good in most cases but... why db date and time data types are not supported at all ?
Thank you.
kind regards
Mario
Offline
TDatetime.
Perhaps I haven't correctly understood 5.1.2 of SAD : "Delphi TDateTime properties will be stored as ISO 8601 text in the database".
What are the delphi published property that the framework threats as a DB date , time or timestamp ? (In some cases I need milliseconds).
Offline
For external databases, TDateTime will be stored as native DB date/time.
For the SQlite3 internal engine, it will be stored as ISO 8601 text.
But the time value is ranged to the second.
What you can do is use your own time type, e.g.
type TPrecDateTime = TDateTime;
Which will be stored as double in the DB, with resolution up to the millisecond.
Offline
Thank you very much.
Mario
Offline
Hi AB,
I'm beginning to know a bit more your fantastic framework and have a question about ID field : it is defined as Integer.
As stated in doc, in sqlite it is an int64 , but in delphi , AFAIK, it is an int32.
One of my tables will grow till int32 capability in short time (few years I suppose) : is it possible , or planned, to use an int64 for the id property ?
Offline
As explained in the doc, the ID field has to map a pointer/TSQLRecord, so that it would be referenced for one-to-one or one-to-many relationship as TSQLRecord published properties.
This is the reason why it should be an Int32.
If you use RecordReference, there is a limitation to 2^24 rows, by design.
But not for plain IDs.
I honestly doubt you would have more than 2^32 rows in your table.
The SQlite3 or external database would be stucked before.
Offline
Yes AB,
i'll not maintain 2^32 rows in db, because i'll reorganize the table periodically, so there will be on line much less records, but the id will increase.
Perhaps restart from zero will not be a problem , because the id will not have a refererence on other tables.
The fact is that we are using up to 64 bit to store values, without having the opportunity to reuse them.
Offline
Pages: 1