The Demo consists of two SubFolders (one for SQLite, the other for ADOJet) -
and the SQLite-Demo depends on the latest vbRichClient5-Version 5.0.15 (May 2014) -
so, make sure you grabbed the last one from here: http://vbrichclient.com/#/en/Downloads.htm
Ok, the CSV-Demo Download is this one here:
http://vbRichClient.com/Downloads/CSVImportDemo.zip
(the above Demo-download is about 800KB in size because it contains a larger example CSV-file from here:
http://support.spatialkey.com/spatia...mple-csv-data/)
The two examples in the two separate Folders show, how to perform Bulk-Inserts
against the two different DB-Engines with the best possible performance, whilst
parsing the Import-Records out of a CSV-File - (there's also a larger CSV-File to
test against, but this one will be automatically generated when the SQLite-Demo starts.
The Zip-included, smaller CSV-File contains about 36,000 Records - the autogenerated
larger one will contain a bit more than 1Mio Records.
Timed Performance:
SQLite has a performance-advantage of about factor 4.5 over ADO/Jet
On the smaller CSV:
SQLite: about 250msec
ADOJet: about 1200msec
On the larger CSV (1Mio Records):
SQLite: about 7.5sec
ADOJet: about 34sec
SQLite
Image may be NSFW.
Clik here to view.
ADOJet
Image may be NSFW.
Clik here to view.
The ADOJet-example is working in dBase-ISAM-mode, which allows a bit more
Space again, since the max size for each *.dbf-table-file is 2GB (whilst for
"normal single-file Jet *.mdbs" this 2GB limit already kicks in on the DB-File itself
(all tables, all indexes).
The dBase-ISAM-Mode was suggested by dilettante in this thread here:
http://www.vbforums.com/showthread.p...ursor-Location
Though the ADOJet-Demo (despite the dBase workaround) still has the following limitations:
- no convenient single-file-DB (SQLite handles everything in a single-file in the same way as *.mdbs)
- 2GB limit per DBF-table File (SQLite can handle filesizes > 100GByte)
- no Unicode-Support (SQLite is fully unicode-capable)
- 8Char-limitation in the Table-FieldNaming (no such restriction in SQLite)
- 8Char-limitation in the DBF-Table-File-name (no such restriction in SQLite)
- wasted space in the created files, due to fixed-length-Text-Fields (DBF-filesize in this example is about 4 times larger than the generated SQLite-DB)
- factor 4.5 slower with Bulk-Inserts than SQLite
- 2GB FileSize-limitation of the CSV-Import-File (the vbRichClient-cCSV-Class has huge-file-support)
The latter point can be resolved of course with ones own implementation of a CSV-parser,
in conjunction with a Class that also allows for huge-file-handling (> 4GB).
The only advantage the ADOJet approach offers, is "zero-deployment" (ADOJet comes preinstalled on any current Win-Version).
Well - your executable will have to be deployed of course also in the ADOJet-case. ;)
So the "disadvantage" with the vbRichClient5-builtin SQLite-engine is, that you will have
to ship "3 more dll-binaries" with your executable (7z-compressed this is ~1.6MB, not really
worth mentioning nowadays) - also regfree-support is only 3-4 lines of code away with
any vbRichClient5-based application (without any manifests).
Those who want to keep a good "competitive advantage" over other solutions in this category,
should definitely re-consider - and take SQLite into account. :)
Olaf
and the SQLite-Demo depends on the latest vbRichClient5-Version 5.0.15 (May 2014) -
so, make sure you grabbed the last one from here: http://vbrichclient.com/#/en/Downloads.htm
Ok, the CSV-Demo Download is this one here:
http://vbRichClient.com/Downloads/CSVImportDemo.zip
(the above Demo-download is about 800KB in size because it contains a larger example CSV-file from here:
http://support.spatialkey.com/spatia...mple-csv-data/)
The two examples in the two separate Folders show, how to perform Bulk-Inserts
against the two different DB-Engines with the best possible performance, whilst
parsing the Import-Records out of a CSV-File - (there's also a larger CSV-File to
test against, but this one will be automatically generated when the SQLite-Demo starts.
The Zip-included, smaller CSV-File contains about 36,000 Records - the autogenerated
larger one will contain a bit more than 1Mio Records.
Timed Performance:
SQLite has a performance-advantage of about factor 4.5 over ADO/Jet
On the smaller CSV:
SQLite: about 250msec
ADOJet: about 1200msec
On the larger CSV (1Mio Records):
SQLite: about 7.5sec
ADOJet: about 34sec
SQLite
Image may be NSFW.
Clik here to view.
ADOJet
Image may be NSFW.
Clik here to view.
The ADOJet-example is working in dBase-ISAM-mode, which allows a bit more
Space again, since the max size for each *.dbf-table-file is 2GB (whilst for
"normal single-file Jet *.mdbs" this 2GB limit already kicks in on the DB-File itself
(all tables, all indexes).
The dBase-ISAM-Mode was suggested by dilettante in this thread here:
http://www.vbforums.com/showthread.p...ursor-Location
Though the ADOJet-Demo (despite the dBase workaround) still has the following limitations:
- no convenient single-file-DB (SQLite handles everything in a single-file in the same way as *.mdbs)
- 2GB limit per DBF-table File (SQLite can handle filesizes > 100GByte)
- no Unicode-Support (SQLite is fully unicode-capable)
- 8Char-limitation in the Table-FieldNaming (no such restriction in SQLite)
- 8Char-limitation in the DBF-Table-File-name (no such restriction in SQLite)
- wasted space in the created files, due to fixed-length-Text-Fields (DBF-filesize in this example is about 4 times larger than the generated SQLite-DB)
- factor 4.5 slower with Bulk-Inserts than SQLite
- 2GB FileSize-limitation of the CSV-Import-File (the vbRichClient-cCSV-Class has huge-file-support)
The latter point can be resolved of course with ones own implementation of a CSV-parser,
in conjunction with a Class that also allows for huge-file-handling (> 4GB).
The only advantage the ADOJet approach offers, is "zero-deployment" (ADOJet comes preinstalled on any current Win-Version).
Well - your executable will have to be deployed of course also in the ADOJet-case. ;)
So the "disadvantage" with the vbRichClient5-builtin SQLite-engine is, that you will have
to ship "3 more dll-binaries" with your executable (7z-compressed this is ~1.6MB, not really
worth mentioning nowadays) - also regfree-support is only 3-4 lines of code away with
any vbRichClient5-based application (without any manifests).
Those who want to keep a good "competitive advantage" over other solutions in this category,
should definitely re-consider - and take SQLite into account. :)
Olaf