using UniDAC's SQLite provider to play with a SQLite database, unfortunately, whenever reading a "timestamp" field, the result is always 12/30/1899, we're currently using UniDAC version 5, we also have a few older versions, all of them have the same issue.
using UniDAC's SQLite provider to play with a SQLite database, unfortunately, whenever reading a "timestamp" field, the result is always 12/30/1899, we're currently using UniDAC version 5, we also have a few older versions, all of them have the same issue.
thoughts?
thoughts?
Have you tried other libraries as well?
ReplyDeleteI suspect this could be an SQLite problem...
A
Can it be a format conversion issue? Can the date format be set in the database install, or per db instance? Can it be set in the driver, or does it follow the current OS format?
ReplyDeleteIs this relevant?
http://stackoverflow.com/questions/3439624/sqlite-timestamp-formatting
basically there's a problem reading the timestamp field, a simple SELECT * FROM TABLE(which contains timestamp fields) will always return 12/30/1899 in stead of the actual timestamp value, using a third party sqlite reader I can see the "real" value.
ReplyDeleteAndrea Raimondi other libs are out of the question, we're using postgres as "the killer" and "sqlite" for easy testing of new features, etc. unidac gives us the ability to change "provider" without changing code...
I suggest you post your question in the FireDAC forum (https://forums.embarcadero.com/forum.jspa?forumID=502). Dmitry Arefiev seems to be there all the time and answers questions very quickly.
ReplyDeletePaul Thornton UniDAC is from DevArt and has nothing to do with FireDAC
ReplyDeleteDorin Duminica I am just saying it could be a SQLite problem, I'd give a go to some other library just to make sure the field shows right.
ReplyDeleteYou see, the problem with SQLite is that you can never be sure what there will be in the fields :)
If other libraries show the same result, then it's a data problem in your database.
You can even just try some application whch manages SQLite databases, just to see if your problem is in the library - I think you'll find it's a data problem.
Stefan Glienke - Oops, sorry. FireDAC would do the job though :)
ReplyDeletePaul Thornton Knowing the quality of DevArt products and those that contain Fire in their name and are related to EMBT I would go with UniDAC :)
ReplyDeleteDorin Duminica Check the format for your timestamp field because according to SQLite documentation the format has to be "YYYY-MM-DD HH:MM:SS" maybe you can specify that - otherwise UniDAC might be missing correct conversion.
tried that, a TUniConnection object has "provider specific options", in these options there's DateFormat and TimeFormat, tried them independently and together, nothing changes >.<
ReplyDeleteStefan Meisner - I was skeptical at first, but FireDAC (AnyDAC) is a really nice product. I've just finished converting a pretty large project from FIBPlus to FireDAC and it was a very smooth and pleasant experience :)
ReplyDeletealright, spent enough time on this, apparently, changing the field type form "timestamp" to "double" fixes the issue, in addition, I've tested with another third-party sqlite application, this one didn't properly read the timestamp field, oh well, lucky I can change field type and get away with it (:
ReplyDeleteI told you it was bloody SQLite... I hate that "engine", I despise it so much...
ReplyDeleteAndrea Raimondi yeah, it's weird, I wonder why they went with put anything everywhere approach.... anyways, I need a replacement for postgres without going through the hassle of installing postgres for a demo or whatever, so, SQLite is a good drop-in replacement...
ReplyDeleteMy first port of call with any unexpected SQLite behavior is to see what the official command line client returns. Might be worth pinging DevArt support to see what they say.
ReplyDeleteStefan Glienke FireDAC looked like an excellent product and had a good reputation before EMBT bought them.