Re: [sqlite] What wrapper for SQLite?
I've been using SQLite from Delphi. I found it easiest to use the native API, and put my own wrappers around it when necessary. In general I've kept it pretty simple, because I'm using SQLite as an intermediate database to manage data conversions. For the main data store of an application you'll want something a little more sophisticated. Clay Dowling Joe DiMaggio said: > Hello, > > I need a server-less SQL engine. Unless someone recommends a better tool > (embedded FireBird? Something else?), I'm thinking of using SQLite. > > Problem is, several wrappers are listed in the SQLite wiki. Can you > recommend one, ideally under active development, easy to use, etc. > > - Aducom open-source Delphi/BCC SQLite components > http://www.aducom.com > > - ZeosLib > http://sourceforge.net/projects/zeoslib/ > > - DISQLite3 > http://www.yunqa.de/delphi/sqlite3/ > > - LibSQL > http://libsql.dubaron.com/ > > - Simple Sqlite 3.0 for Delphi > http://www.itwriting.com/sqlitesimple.php > > Thank you. > > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.1.394 / Virus Database: 268.9.1/369 - Release Date: 19/06/2006 > > > -- Simple Content Management http://www.ceamus.com
Re: [sqlite] What wrapper for SQLite?
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.
Re: [sqlite] What wrapper for SQLite?
> 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! Problem with wrappers is, most of them are unfinished. The authors play with them to get some things work and forget about it after their problem has been solved. Minimal and complete libraries are non-trivial. Especially annoying is the situation, where the developer made a decision to use the wrapper and becomes confronted with missing functionality at some point in the future. The required thorough evaluation of the wrappers limitations might have been better spent in writing your own version ... Additionally, maintenance problems and dependencies (commercial or not) might occur, mostly things probably avoided from users of software in the style of sqlite (KISS as someone cited yet). Not touching Delphi for almost ten years - why not writing a minimal wrapper and extending step by step. I do it with my C++ wrappers routinely. It was most of the time the better solution in most aspects (time, simplicity). Micha --
Re: [sqlite] What wrapper for SQLite?
"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. -- D. Richard Hipp <[EMAIL PROTECTED]>
Re: [sqlite] What wrapper for SQLite?
On 6/20/06, John Stanton <[EMAIL PROTECTED]> wrote: Costas Stergiou wrote: >>Hello, >> >>I need a server-less SQL engine. Unless someone recommends a better tool >>(embedded FireBird? Something else?), I'm thinking of using SQLite. >> >>Problem is, several wrappers are listed in the SQLite wiki. Can you >>recommend one, ideally under active development, easy to use, etc. >> >>- Aducom open-source Delphi/BCC SQLite components >>http://www.aducom.com >> >>- ZeosLib >>http://sourceforge.net/projects/zeoslib/ >> >>- DISQLite3 >>http://www.yunqa.de/delphi/sqlite3/ >> >>- LibSQL >>http://libsql.dubaron.com/ >> >>- Simple Sqlite 3.0 for Delphi >>http://www.itwriting.com/sqlitesimple.php >> >>Thank you. >> > > > Having done a similar research in the past I would certainly suggest to not > use any library and use directly the sqlite procs. All you need is a file to > declare the functions in Delphi and then just use the functions directly. > > Personally, I have just created some simple wrapper functions in Delphi > (very simple - 3 lines each) to make it a bit easier to call the SQLIte > functions. > > Using a wrapper is usually bug-prone (unfortunately most of them have bugs) > and it usually wraps around the TDataset which is not a good idea (unless > you are using bound controls). > Also, if you use a wrapper you will need to learn 2 APIs: SQLite's and the > LIB's, which is again a bad idea. > > Hope this is of some help, > Costas > > P.S. I am not the 'do-it-yourself' kind but in this case, it is really > better to use sqlite directly! > > > 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! -- Cory Nelson http://www.int64.org
Re: [sqlite] What wrapper for SQLite?
Costas Stergiou wrote: Hello, I need a server-less SQL engine. Unless someone recommends a better tool (embedded FireBird? Something else?), I'm thinking of using SQLite. Problem is, several wrappers are listed in the SQLite wiki. Can you recommend one, ideally under active development, easy to use, etc. - Aducom open-source Delphi/BCC SQLite components http://www.aducom.com - ZeosLib http://sourceforge.net/projects/zeoslib/ - DISQLite3 http://www.yunqa.de/delphi/sqlite3/ - LibSQL http://libsql.dubaron.com/ - Simple Sqlite 3.0 for Delphi http://www.itwriting.com/sqlitesimple.php Thank you. Having done a similar research in the past I would certainly suggest to not use any library and use directly the sqlite procs. All you need is a file to declare the functions in Delphi and then just use the functions directly. Personally, I have just created some simple wrapper functions in Delphi (very simple - 3 lines each) to make it a bit easier to call the SQLIte functions. Using a wrapper is usually bug-prone (unfortunately most of them have bugs) and it usually wraps around the TDataset which is not a good idea (unless you are using bound controls). Also, if you use a wrapper you will need to learn 2 APIs: SQLite's and the LIB's, which is again a bad idea. Hope this is of some help, Costas P.S. I am not the 'do-it-yourself' kind but in this case, it is really better to use sqlite directly! 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)?
RE: [sqlite] What wrapper for SQLite?
> Hello, > > I need a server-less SQL engine. Unless someone recommends a better tool > (embedded FireBird? Something else?), I'm thinking of using SQLite. > > Problem is, several wrappers are listed in the SQLite wiki. Can you > recommend one, ideally under active development, easy to use, etc. > > - Aducom open-source Delphi/BCC SQLite components > http://www.aducom.com > > - ZeosLib > http://sourceforge.net/projects/zeoslib/ > > - DISQLite3 > http://www.yunqa.de/delphi/sqlite3/ > > - LibSQL > http://libsql.dubaron.com/ > > - Simple Sqlite 3.0 for Delphi > http://www.itwriting.com/sqlitesimple.php > > Thank you. > Having done a similar research in the past I would certainly suggest to not use any library and use directly the sqlite procs. All you need is a file to declare the functions in Delphi and then just use the functions directly. Personally, I have just created some simple wrapper functions in Delphi (very simple - 3 lines each) to make it a bit easier to call the SQLIte functions. Using a wrapper is usually bug-prone (unfortunately most of them have bugs) and it usually wraps around the TDataset which is not a good idea (unless you are using bound controls). Also, if you use a wrapper you will need to learn 2 APIs: SQLite's and the LIB's, which is again a bad idea. Hope this is of some help, Costas P.S. I am not the 'do-it-yourself' kind but in this case, it is really better to use sqlite directly!
