"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]>
