----- Original Message -----
From: "Steve O'Hara" <[EMAIL PROTECTED]>
SqliteSpy is a nice tool but this is a weakness, not a strength - we
used to call this sort of thing "built-in obsolescence". Woudn't it be
better for you if you didn't have to track changes made by Richard to
the engine?
This is also a problem with quite a few of the wrappers that embed the
engine.
Unfortunately not all of us have an option. Here's some examples from my
own experiences from incorporating a wrapper for SQLite in .NET:
- The Compact .NET Framework can't pass 64-bit numbers by value, only 32-bit
... so all functions that require a double or an int64 have to be wrapped by
another C function that takes pointers to those values instead, and then
forwards the dereference to the actual SQLite call.
- The CF also cannot call cdecl functions, all API calls in a DLL must be
stdcall. So every API function in sqlite has to be wrapped with a stdcall
version which forwards to the cdecl version.
- The .NET framework (both full and CF) cannot pass cdecl callback function
pointers. All callback functions must be stdcall, so again, all callbacks
have to be wrapped.
- Many folks have added encryption support to the library, including me.
Mine is specific to the Windows platform (it was my way of adding encryption
and yet not invalidating DRH's paid package).
None of these changes merit merging with the core sqlite codebase, yet all
are required in order to have a fully-functioning .NET provider for SQLite.
Robert
