Different tasks require different approaches. Therefore DISQLite3 offers three levels of abstraction to Delphi developers:
1. The full SQLite3 API, all contained in a single Delphi unit. Best suited to all who like direct access to the SQLite3 interface or want to write their own, app-specific wrappers around it. AFAIK, DISQLite3 is the only Delphi library to surface the _complete_ SQLite3 API. 2. Component wrappers: TDISQLite3DataBase wrapps a SQLite3 database handle. TDISQLite3Statement encapsulates a prepared statement handle. Both components introduce Delphi exceptions at critical points plus a few Delphi-centric functions to work with AnsiStrings and WideStrings, for example. TDISQLite3Statement also takes care of SQLITE_SCHEMA errors and automatically re-prepares a statement if required. Sources are included. 3. A SQLite3 TDataSet descendant to work with Delphi's data-aware components and report generators. It supports automatic updates via TDataSetProvider / TClientDataSet and can be of great benefit to true RAD developers. Source code is included. The aim for DISQLite3 is to keep the API up to date with the SQLite3 developments and improving the various wrapper levels. You comments and suggestions are very welcome! If you are interested in DISQLite3, it is available for download from http://www.yunqa.de/delphi/sqlite3/. Ralf >"Cory Nelson" <[EMAIL PROTECTED]> wrote: >> > > >> > > I would certainly suggest to not >> > > use any library and use directly the sqlite procs. >> > > >> > I would endorse that approach. The Sqlite API is simple and easy to >> > use, so why not take advantage of that and KISS (Keep It Simple Senor)? >> > >> >> A lot of the time using the vanilla API keeps you from coding in the >> style most suited for a modern lang, which may only help introduce >> bugs which the dev isn't used to worrying about. I don't think it's >> right to recommend using it when there are wrappers tailored to keep >> the dev thinking in their own lang. >> >> You certainly don't gain anything by using the flat API over a >> wrapper, unless the wrapper is bloated/buggy! >> > >I have to agree with Cory. I tired to keep the native SQLite >API simple, but because of the need to keep it backwards >compatible, it has developed a few warts. Prime example: when >sqlite3_step() fails, you have to make a call to sqlite3_reset() >to get the error code, which might be SQLITE_SCHEMA which means >you should run sqlite3_prepare() again and retry. A good wrapper >should hide these details and make the API even simpler than it is. > >That said, I also observer that there are a lot of bad >wrappers out there - wrappers that hide no details or warts >of the native SQLite interface but instead introduce new >warts and bugs of their own. If your only choice is a bad >wrapper, then the native API is often better. But a good >wrapper can often be much better than the native API. > >I have no experience with any of the delphi wrappers so >I cannot comment on whether or not they are good or bad. >Perhaps all of the delphi wrappers are such that you really >would be better of going directly to the native SQLite API. >If so, then it argues for writing a better wrapper for >Delphi, not for giving up on using wrappers.
