Re: Q: performance comparison SE <-> dBase

fliauw@inter.NL.net (Fred Liauw) wrote: >Hello all, > >I'm developing a list-function which lets users type in a few >characters...etc... >Can someone explain this difference to me? I'm really frustrated about this. >Am I doing something terribly wrong? Ok, no code was provided, so I'll assume something like the following pseudocode: declare xx cursor for select name from atable where name >= ?; loop get_next_key_and_add_it_to( aname ); open xx using :aname; fetch xx into :dispname; display_into_current_field( dispname ); ! you might also fetch X additional names to fill in screen list close xx; again dBase uses the keyed name to set the btree index position, whereas SQL queries return solution sets. This is a low-level index operation vs. a high level relational query. I don't think Novell vs Unix or dBase vs SQL is the proper question, the question is what are you forcing your chosen platform to do? In dBase (or Btrieve or ctree etc), the entire index is the solution set, so the 'engine' can quickly find the first record where name >= 'Z'. Each time another letter is typed, the file position can be quickly updated to point to the next record. In SQL, the table must be processed to find all rows "where name like 'Z%'". Each time another letter is typed, the cursor must be closed and re-opened with the new value to find the solution set. While the instant-update-as-typed feature is neat and very interactive, I can't think of a way to do the equivalent operation efficiently using SQL.