So, what's your theory? You have the data, you'll need to make the hypotheses and test them out. Perhaps they are storing the dates as a offset in seconds since June of 2003, or perhaps there's something else going on. If you know the correct date for a couple of records, you should be able to match them against these 9-digit elements and work out the pattern.
In SQLite3, if you issued a "SELECT * FROM <table>" do you see the same values you see in VFP?
I don't know why they would be coming back as memo fields.
So, I just installed SQLite3 and the ODBC driver, created a test database and table with a date and datetime, populated it, created a DSN for VFP to connect to, queried the database table and got back a date and a datetime.
You'll need to supply more information, or work it out for yourself.
On Thu, Apr 27, 2017 at 2:36 PM, José Olavo Cerávolo joceravolo@yahoo.com wrote:
Ok, here's the information I get with SQLite3, the Dates are stored with 9 characters.
database page size: 4096 write format: 2 read format: 2 reserved bytes: 0 file change counter: 347 database page count: 532 freelist page count: 0 schema cookie: 45 schema format: 4 default cache size: 0 autovacuum top root: 39 incremental vacuum: 1 text encoding: 1 (utf8) user version: 0 application id: 0 software version: 3014000 number of tables: 23 number of indexes: 14 number of triggers: 0 number of views: 0 schema size: 8265 Subject: Re: Reading from SQLite Message-ID: CACW6n4sokfifY57-mWO4ZGW1wv=o_J0MnkK5dXMmJwEkRyhhpg@mail.gmail.com Content-Type: text/plain; charset="utf-8"
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? José Olavo Cerávolohttp://www.ceravoloconsulting.com/
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html
[excessive quoting removed by server]