Hi Bonnie,

>I was mainly curious about the speed differences between the different ways of doing this kind of lookup, but for the most part, you're right that an application shouldn't be shuttling vast amounts of data over the wire anyway. <g>
I was NOT critizing your test scenario!
One of the things I have no idea at the moment is how to handle
*really* disconnected situations: the roadwarrior having loaded
some data from the server onto the laptop.
Where is the cutoff point to export into MSDE or
just use XML to persist and later synchonize?
The data sizes we had when using db3 probably can be
handled in memory sequentially (The RAM is much bigger than
the disks of the late eighties). When is n**2 good enough,
when must we move to n log n with better access strategies ?

>But, in order to get any kind of significant numbers in the benchmarking,
>I felt I needed large numbers and that's why I compared with
>100, 1000 and 10000 rows.
>But, in the real world, I wouldn't have such large numbers.
But it sure is useful to know when and where the degradation will happen -
don't apologize for following the right way to conduct such tests <g>.

>However, that said, I can see where this type of benchmarking might be useful to know
>in situations where one might be doing some batch-processing of large amounts of data,
>maybe something that's not done on a day-to-day basis in your app,
>but perhaps a once-in-awhile kind of thing, or maybe a month-end report or some such stuff.
>You'd probably want that optimized.
>So, you're right that tnis might require some additional benchmark tests ...
>particularly with setting a PK and seeing how fast the .Find is.
>But, I'll leave that to others for now,
>I've already wasted several hours on this benchmarking.
>Wanna do it? <g>

It'll come to that some day, just to give me a better handle or
some guideline for my coding practices...
No problem to show it here and get a few other ideas.
You'll get a notice for sure - promise.

>BTW, the RAM on my laptop isn't bad, 512, but it isn't exactly a lot either.
>Another interesting benchmark (if anyone were interested in trying it)
>would be to try the same amount of data on different computers with differing RAM
>to see how much RAM plays into it.
Trick of the trade: boot up with different /maxmem switches in your boot.ini!
Helps simulate different environments without toooooo much install trouble.
With some other tricks you can build a nice perf picture even with possible
bottlenecks showing using just 2 or 3 computers <g>.
Laptops are great for this kinda work...

Regards

thomas