![]() 'now we can test, what Field-Types the Converter has applied to the first imported Table 'and use the RC5-Converter for import (passing those two Cnn-Objects along). Set CnnDst = New_c.Connection(SQLiteFile, DBCreateNewFileDB) If New_c.FSO.FileExists(SQLiteFile) Then New_c.FSO.DeleteFile SQLiteFile 'open the destination as an SQLite-Connection with the ending *.db or *.db3):Ĭode: Sub Import(MDBFile As String, SQLiteFile As String)ĬnnSrc.Open "Provider=.4.0 Data Source=" & MDBFile Here is the code you can run, to convert an *.mdb to an SQLite-DBFile (e.g. Yes, but first let's take a look, why it comes to that situation (of always "long dates" being imported): automatically performing the right mappings to normal VBDate-Variables when you access these Fields over question is it possible to change the dates by code from long format to short one"] SomeField Time will ensure "simple Time ISO-Format" (only "hh:mm:nn") at the SQLite-TextStorage-Level SomeField ShortDate will ensure "short ISO-Format" (only "YYYY-MM-DD") at the SQLite-TextStorage-Level SomeField Date (as well as SomeField DateTime) will ensure "long ISO-Format" at the SQLite-TextStorage-Level If you want the cRecordset-Class to do all these "ISOTextDate-to-VBDate" conversions for you (under the covers),Īll you need is, to "give it a hint" (via your TableDefs Field-TypeNames): and use VBs CDate() Function, to convert such stored ISO-Texts into a normal VB-Date-Variable yourself but you'll have to make sure yourself, that you store it later in SQLite as "ISO-Text-Format" (when setting the Rs-Value) instead you will get your Rs("MyISODateField").Value out as a normal Text-String. ![]() ![]() Such a TextField-Type will not be interpreted or changed in any way by the RC5-Recordset-wrapper: one has to define them at Create Table-Time as Text. If one does not want any RC5-Wrapper support with DateFields, then: When we read DateValues out of Recordset-Fiels (or putting them into Rs-Fields or CommandObjects) via VB6/VBA or VBScript. The second question is, how those (low-level, as ISO-Date-String) stored SQLite-Dates are represented "on the other side of the wrapper", (because that's compatible with the built-in SQLite Date-Time-Functions, and also commonly used in other SQLite-Tools and -wrappers). So, these two "lower-level-StorageClass" DateFormats (Integer and Text) are supported when it comes to Date-Field-passing into the builtin functions.Īnd the RC5-COM-wrapper for SQLite has choosen only one of the above possible "Storage-Classes" to store Dates: or a Text-Field-Value (in ISO-DateString-Format) either an Integer-Field-Value (stored as a Unix-Epoch) The SQLite-engine has built-in Date-Functions of course.Īnd these expect "Field-Input" in two formats: Another issue is that people often use a layer between their application and SQLite, and those layers often play reindeer games to try to map data types.Well, the non-SQLite-expert has spoken, I guess.įYI (although you never read any of these, I know).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |