>Instead you want to hide behind a trivial argument to avoid having to learn anything new. I say trivial because the benefit (if any) gained by the speed of SEEK() is trivial if it keeps you from learning how to develop a C/S application. But, of course, you don't know this because you never have in the first place and your resistance will keep you from doing so in the future.


Jeff,

Exccuse me but Ed did tell us, as a matter of fact I believe the message was addressed to you, that he has developed C/S apps and more than one of them at that. Your personal slights are not helping your argument, they are actually detracting from them.

Ed, never said that SEEKing on native tables is always the preferable way fo doing anything, he did say that SEEKing against native tables is faster and it is. He did not say that using SEEK was scalable because I don't think he ever would he has too much experience to make a foolish statement like that.

I think a good read for everyone in this thread on SEEK would be the Fox.wiki.com pages titled (I think) AdaptiveDesign and AnticipitoryDesign or something like that. It has to do with how much benefit is gained and at what cost when anticipating future requirements that are not clearly part of the curretn specs.