Hi Ted, The dates on the existing table are not .NULL..When I get the date using what you suggested, datetime(yourfield,'unixepoch','localtime'), I get this date on an MEMO field 1984-10-05 23:00:00. This date is not the actual date on the other application. The date should be in 2017.The actual value stored on the actual SQLite table is 459316800. There's a disconnect from what the other application is saving to what I am able to read. I am not able to talk to the other application programmer. I've read a lot of documentation about SQLite, but nothing that could actually help me. Thanks, Jose.
Message: 7 Date: Wed, 26 Apr 2017 16:58:56 -0400 From: Ted Roche tedroche@gmail.com To: profoxtech@leafe.com Subject: Re: Reading from SQLite Message-ID: CACW6n4tEd4w_W0iK59ND+c30YH+TnqHN6GfDQ+ZgesXuymtCCw@mail.gmail.com Content-Type: text/plain; charset="utf-8"
.NULL. is a perfectly valid date.
If you're getting numbers, you're likely getting dates stored as days since some arbitrary date. Try:
select datetime(yourfield,'unixepoch','localtime') from yourtable;
José Olavo Cerávolo http://www.ceravoloconsulting.com/
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---
On Thu, Apr 27, 2017 at 12:17 PM, José Olavo Cerávolo joceravolo@yahoo.com wrote:
Hi Ted, The dates on the existing table are not .NULL..When I get the date using what you suggested, datetime(yourfield,'unixepoch','localtime'), I get this date on an MEMO field 1984-10-05 23:00:00. This date is not the actual date on the other application. The date should be in 2017.The actual value stored on the actual SQLite table is 459316800.
Well, that's weird. THE SQLite function datetime() is expecting a number of 10 digits, so that's not the encoding scheme. Can you use a tool like SQLite3 to look at the actual data in the SQLite table and confirm this isn't a problem with ODBC or Fox's intepretation of the data?
Try this page as well:
http://www.sqlite.org/lang_datefunc.html
Time Strings
A time string can be in any of the following formats:
1. *YYYY-MM-DD* 2. *YYYY-MM-DD HH:MM* 3. *YYYY-MM-DD HH:MM:SS* 4. *YYYY-MM-DD HH:MM:SS.SSS* 5. *YYYY-MM-DD**T**HH:MM* 6. *YYYY-MM-DD**T**HH:MM:SS* 7. *YYYY-MM-DD**T**HH:MM:SS.SSS* 8. *HH:MM* 9. *HH:MM:SS* 10. *HH:MM:SS.SSS* 11. *now* 12. *DDDDDDDDDD*
On Thu, Apr 27, 2017 at 1:04 PM, Ted Roche tedroche@gmail.com wrote:
On Thu, Apr 27, 2017 at 12:17 PM, José Olavo Cerávolo joceravolo@yahoo.com wrote:
Hi Ted, The dates on the existing table are not .NULL..When I get the date using
what you suggested, datetime(yourfield,'unixepoch','localtime'), I get this date on an MEMO field 1984-10-05 23:00:00. This date is not the actual date on the other application. The date should be in 2017.The actual value stored on the actual SQLite table is 459316800.
Well, that's weird. THE SQLite function datetime() is expecting a number of 10 digits, so that's not the encoding scheme. Can you use a tool like SQLite3 to look at the actual data in the SQLite table and confirm this isn't a problem with ODBC or Fox's intepretation of the data?
[excessive quoting removed by server]
-
José Olavo Cerávolo -
Stephen Russell -
Ted Roche