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 <jocerav...@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_j0mnkk5dxmmjwekryh...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Thu, Apr 27, 2017 at 12:17 PM, Jos? Olavo Cer?volo > <jocerav...@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] _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/cacw6n4uhlygealqovgqg9c2juct2vpdbjcuezgfs1sopitk...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.