2013/7/19 RSmith <rsm...@rsweb.co.za> > Being a Delphi Developer (mostly) and using SQLite quite often, I can tell > you some things about it: > > You can easily wrap an SQLite DLL in Delphi, there are many free > implementations of this, if you dont have one, send me a mail and I will > supply one. SEE will work as easily and I don't know of any restriction > about it being used as a DLL, excepting to disguise it for obvious reasons. > (not least among which, the security of your own system). >
We already have a wrapper on SQLite.dll (otherwise we won't be able to develop a SQLite database manager :) It's a .pas file with function calls declared like: ... function sqlite3_open_v2(const Filename: PAnsiChar; var Base: PSQLite3; Flags: Integer; const Vfs: PAnsiChar = nil): Integer; cdecl; external 'sqlite3.dll'; ... It just wasn't clear how can we use SEE in this case. > > Further to this, DISQLite works really well as a native implementation in > specifically Delphi, and will work very well for your purpose. It is > however commercial so there is a cost consideration. (Yes it has a > free-for-personal-use option, but any form of commercial application needs > the commercial version). The only possible disadvantage I can level at it > is that to use new adaptations of the SQLite system requires a recompile > and update as opposed to just shipping another dll - but then if the dll > supports new API calls, much the same is true. If security is a concern and > it is a wholly Delphi-integrated product, I would suggest going with > DISQLite if feasible. > I'm unsure about advantages of using DISQLite vs calling directly SQLite.dll. The main advantage is statically linking but we'll try to manage it via compiling amalgamation to .obj and linking. As for performance. There can't be a significant difference between these solutions, in my opinion. 99% of the time will be spent inside SQLite. Thanks, anyway. We'll give it a try. > > Lastly, it seems that either you wish to use different forms of > encryptions to further subterfuge or obscure database content, or that you > expect to be needing to open datasets with hitherto unknown encryptions. if > it is the former, I can honestly say it is not needed, just use whatever > you like, most of the supported encryptions have ratings way above military > specification when using proper keys etc. If it is the latter case, you > can't open Databases of which you don't know exactly the encryption and > keys... there is no way to do this, else the whole encryption racket would > be rather useless. I guess you're right. > > > > > On 2013/07/19 15:52, Ralf Junker wrote: > >> On 19.07.2013 15:27, Sqlite Dog wrote: >> >> * Statically link SQLite to your Delphi application. My DISQLite3 >>>> enables you to do just that and has numerous extensions: One is a >>>> custom encryption algorithm. This is not compatible with SEE, >>>> but if you like I can replace it with your original SEE code for you. >>>> >>>> >>>> http://www.yunqa.de/delphi/**doku.php/products/sqlite3/**index<http://www.yunqa.de/delphi/doku.php/products/sqlite3/index> >>>> >>> Is it a pascal wrapper around SQLite or something bigger? >>> >> DISQLite3 is the only Delphi product which includes the _complete_ >> SQLite API, AFAIK. Using register calling conventions and the Delphi >> memory manager, DISQLite3 surprised many users to perform noticeably >> faster than other implementations. Features include: >> > etc... > > > > > ______________________________**_________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-**bin/mailman/listinfo/sqlite-**users<http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users> > -- Regards, SqliteDog support team _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
