It's a major update, with the support for compilation without our Enhanced RTL. It should compile from Delphi 3 to Delphi 2007. Just define the {$define NOENHANCEDTRTL} conditional at line 82 of the SQLite3Commons unit, and at line 11 of the SQLite3i18n unit.
We tried to add UNICODE compatibility, that is compilation under Delphi 2009/2010. It was not fully tested yet, but the code has been deeply rewritten, in order to provide compatibility with the String=UnicodeString paradigm of these compilers. The HTTP communication layer is not ready yet (still need to hack the synsock library).
Since our SQLite3 framework is natively UTF-8 (this is the better character encoding for fast text - JSON - streaming/parsing and it is natively supported by the SQLite3 engine), we changed a lot the way our framework used strings. Some string types have been defined, and used in the code for best cross-compiler efficiency (avoiding most conversion between formats):
- RawUTF8 is used for every internal data usage, since both SQLite3 and JSON do expect UTF-8 encoding
- WinAnsiString where WinAnsi-encoded AnsiString (code page 1252) are needed
- generic string for i18n (in unit SQLite3i18n), i.e. text ready to be used within the VCL, as either AnsiString (for Delphi 2 to 2007) or UnicodeString (for Delphi 2009/2010)
- RawUnicode in some technical places (e.g. direct Win32 *W() API call in Delphi 7) - note: this type is NOT compatible with Delphi 2009/2010 UnicodeString
- RawByteString for byte storage (e.g. for FileFromString() function)
- some special conversion functions to be used for Delphi 2009/2010 UnicodeString (defined inside {$ifdef UNICODE}...{$endif} blocks)
- never use AnsiString directly
- the FPC RTTI is not the same as Delphi's... so we had to add a dependency to the external typinfo.pp unit
- the 64 bit compiler is prepared: all optimized asm code blocks have been rewritten into pure pascal, and PtrInt/PtrUInt were used for pointer to integer conversion
- use advanced function inlining and typical FPC optimization where possible
- cross-platform first attempt (not finished yet, only compiled under Win32)
- it's a work in progress: help welcome here!
- SQLite3 database layer updated to version 3.6.22 (corresponding .obj file supplied)
- new communication layer, to be used on a local computer: windows messages (see TSQLRestClientURIMessage class). On a local machine, this is faster than named pipes and http, for small messages (quite as fast as direct access); but named pipes seems to be better for bigger messages
- Windows service access (control and writing), without the standard heavy VCL using data modules
- some speed enhancements, code rewrite and comments added - documentation is quite ready to be posted on this website!
one reaction
1 From A.Bouchez - 21/06/2010, 11:17