Mark and Richard: Thank you all for your well considered comments. I've got enough information to decide to spend some time evaluating SQLite as a replacement DB. I'll cook up some test code as a next step. The example code will be a good starting point.
The comments about the added safety of SQLite is of interest. A bit of information about DBF reliability and recovery; I know about their use inside commercial Customer Relations Management(CRM) software. Goldmine and ACT! both use DBF C libraries in those products. We tested them by doing things like unplugging the computer or resetting the workstations and the servers while the code was running. It completely trashed the DBF's which had to be restored from backups. Breaking software can be fun. The one CRM that does not have that problem that I have found is Maximizer. It uses Pervasive Software's latest version of Btreive, a network type database with recovery. Maximizer crashes result in a DB rebuild on the next program start. It's lookups are very fast too but the databases are specialized in design. They have in recent years tried to put a SQL face on that commercial product. Most of my projects are for applications that are used over many years, 5 to 10 is not unusual. I can't depend on companies like Microsoft et. al. to maintain a compatible product over those time frames. Having the source code "just in case" is a good idea, another to selling point for SQLite. On 8/3/07, Mark Richards <[EMAIL PROTECTED]> wrote: > > john s wolter wrote: > > I have an old Clipper DBF type application that has worked well but > times > > changed and changed long ago. The feature of this DBF, non-GUI, text > > oriented, application is that it is mostly a list lookup application > with > > few DB changes. A separate Admin program does list management. The > list is > > about 10,000 people long. New requirements justify a rewrite of the > > programs. Rewrite environments include Mono's C#, JAVA, Python, C++, > et. > > al. , all of which appear supported by SQLite bindings. > > > > The Clipper application is very fast at these lookups which are at a > > customer service desk where there is a queue of people impatiently > waiting > > in line. Using an incremental lookup text entry box the list quickly > > narrows to just a few entries and then a quick cursor pick chooses the > > correct record. Clipper DBF file indexes are a simple key-value and a > > pointer into a DBF file's records. > > >That is why these lookups are so fast. > A rather wide generalization, don't you agree? There's more to consider. > > >See this xBase file format > > description<http://www.clicketyclick.dk/databases/xbase/format/>. > > It is not a RDBMS as some stated in the past. > This is an old argument and perhaps boils down to semantics. The > specification for a true RDBMS are not met, but this is not to say that > it cannot do the job quite well. It does but the relating isn't built > into the Clipper engine. You have to code for it and make sure it's > enforced. The format is dead without something to drive it. > > > > > I am of the opinion that full SQL engine's set based extractions are too > > slow and may not be suited to an incremental list lookup. However, > SQLite > > appears on the surface to be potentially faster than the its full SQL > engine > > peers. I also like the idea of linking a library into the application, > that > > also looks faster a first blush. > > The fact that CA-Clipper applications (and expansions on the theme in > CA-VO) are not prevalent speaks well of newer, stronger, and more > efficient technologies. I worked in Clipper since Nantucket's first > product right through to the present CA-VO. In its day the format was > all we had and it was wonderful. But no transactions, no rollback, and > record/file locking had to be done manually. Horrors if something > crashed. Fun to recover a DBT whose associated DBF became mangled. > > Certainly for simple and quick tasks a DBF format still works fine and > Clipper will run on just about any old thing. But I would never (now) > in my right mind use DBF in a production setting, just as I would hold > the same restriction to running a Windows server. There are far better > tools that require less time to develop and give greater all-around > performance. I know that's not what you asked :) > > > > > I am wondering if SQLite has features that could be used to make these > > lookups just as quick? Can you point me , so to speak, in the correct > > direction? > > > If you see a performance difference - and it's possible - consider what > SQLite does to protect your data and make access so simple. Protecting > data is not build into the DBF format (there are add-ons that will give > you some of this, but at considerable overhead). Plus, all the Clipper > stuff was (and probably still is) proprietary. > > Comparing just the lookup method (both use b-tree's I believe) does not > take into account the entire picture. > > If you're considering SQLite, you're on the path of a very good choice. > > /m > > > ----------------------------------------------------------------------------- > To unsubscribe, send email to [EMAIL PROTECTED] > > ----------------------------------------------------------------------------- > > -- John S. Wolter President Wolter Works Mailto:[EMAIL PROTECTED] Desk 1-734-665-1263 Cell: 1-734-904-8433
