I think how you are approaching it via a “soft migration” is the best way.

And yes, an Excel VBA example would be very useful.

I’ve built simple C functions to enable me to call VBA user defined functions and to load/unload disk-based databases to/from :memory: dbs, plus a few helper functions such as load to and from CSV files/streams & ranges etc. But would consider changing over to using DHSQLite if/when the core becomes open source.

Tom

regarding the “ultimate goal” (cross-platform – with the main-target Linux) – I’d think that many developers (although yet using windows) are on a similar way with their “migration-plans” currently – we will see the appropriate effects over the next years.

But that’s IMO a longer process, which (in case you already have larger investments into Code that uses “the MS-toolstack”) needs some time – so it has to be a “soft migration”, starting on the Windows-platform itself.

But the longer trend seems clear to me – all the infrastructure-stuff (databases, internet- or RPC-technologies, development-platforms, office-components) should (and will) be cross-platform in the future (and based on opened sources).

BTW, nice allegory in your “SQLite=MP3″ article…

And let me know, if I should write an XL-VBA-Demo, how to use the features of the new wrapper from within Excel.
There’s for example a SQLiteRs.GetADORsFromContent now, which can be used, to transfer the RS-Content directly into an XL-Cellrange – or CnnObj.CreateTableFromRsContent, which is useful e.g. against an InMemoryDB, to beam a resultset directly into memory as a DB-Table – or easy coding for userdefinable functions, which can be implemented in a VBA-Class over
Implements IFunction, etc…

Regards,

Olaf Schmidt

And I REALLY like the ultimate goal of a new VB6 compatible compiler http://www.thecommon.net/index.html

Tom

Good to hear, I’ve twittered the news to the world http://twitter.com/gobansaor/status/1425381593

Also good to hear that you may open source part or all of it in the future, and also like the direction of the project towards reducing dependence on MS’s COM toolset.

Tom

just released a new version of dhSQLite (wrapper-version is now 3.0.2 – sqlite-engine-version is now 3.6.12).

Please read: http://www.TheCommon.net/3.html
and http://www.TheCommon.net/2.html for details…

All Classes are now part of the new dhRichClient3.dll but will remain calling-compatible to your existing VB(A)-source – just register dhRichClient3.dll on your developer-machine and change your project-reference from dhSQLite to dhRichClient3.
Then everything should work as before.

For installation: please read the Readmes in the Download-package – but normally it should be enough, if you place this 3-Dll-set in a Folder (e.g. C:\dhRichClient3\…)
and register only dhRichClient3.dll there.

Regards,

Olaf Schmidt

You’ll need to register the dhsqlite.dll using regsvr32 (regasm is for .NET assemblies) see http://consumerdocs.installshield.com/selfservice/viewContent.do?externalId=Q108199&sliceId=1

Also ensure the sqlite3_engine.dll is on your “path” (which can be quite tricky when dealing with Excel – see http://en.allexperts.com/q/Excel-1059/Calling-DLL-VBA-Excel-1.htm )

Tom

dhSQLite and the other wrappers I mentioned are not ODBC drivers so all you will need is the wrapper’s DLL (sometimes,as with PSSQLITE, you will need the SQLITE3.DLL itself, but most compile this into the wrapper’s DLL).

If you wish to use SQLite via ODBC, then get http://www.ch-werner.de/sqliteodbc/ this is an excellent open source ODBC driver and it seems to work very well (have used it occasionally myself).

Tom

SQLite itself is not callable directly by VBA, so yes you need to pick a wrapper (or write one yourself). Most wrappers like dhSQLite use COM, so yes you would first register the DLL (although datenhaus also provide a registry-free way of using COM dlls).

For a list of other wrappers see http://blog.gobansaor.com/projects/xlite/#comment-4830

Tom