>>>>>>>>Experience with what? With SEEK or with SELECT_SQL?
>>>>>>>>Sorry, but your answer smells bad.
>>>>>>>>
>>>>>>>>>Looks like you have no experience with this Ed. When you do, then we'll talk.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>Well, some points are too obvious to be discussed even, but why do you put SEEK to 'prohibited' list? Do you want to look for one/few record(s) in 10 millions using SELECT-SQL? It's about the same as using rockets for sparrow hunting.
>>>>>>>
>>>>>>>Ed
>>>>>>>
>>>>>>>Given a SQL Server or Oracle backend, how else would you propose finding a single row out of millions... Even if designing a system using native tables, to ensure an upgrade path using a SEEK against base tables strikes me as a bad idea.
>>>>>>
>>>>>>Mark,
>>>>>>The post was not specifically about RDBMS back-end. This is obvious that many people around including myself are intelligent enough to know that SEEK() can be used for native VFP engine only and cannot be used for RDBMS. Sorry, that I have to tell you these facts now.
>>>>>>The problem (if we are still on technical groud) is that a developer cannot design his/her system blinfolded. It means that the first responsibility to assess scope of project, and if situation assumes that VFP interface will use native data, then this developer must use the most efficient way to develop this system. If someone does know what is SEEK about, then 'future upgrade' to RDBMS is really lame excuse.
>>>>>
>>>>>Lame? I would NEVER want to be in a position to tell a client that an upgrade to a backend database would take a significant overhaul of a system I delivered simply because I used an xBase crutch in the original design.
>>>>>
>>>>>Don't misinterpret; IMO SEEK, LOCATE, SCAN etal are powerful tools that give VFP a definite advantage when operating on SQL result sets.
>>>>>
>>>>>I certainly agree that a developer cannot design a system blindfolded... I would add that they SHOULD NOT design a system with blinders that hinder the ability for an application to scale beyond the time when the final payment for services rendered clears the bank
>>>>>
>>>>>Mark
>>>>
>>>>Let's stay on facts. May I ask you 2 plain questions:
>>>>1) Do you use SEEK or SEEK()?
>>>
>>>Typically SEEK, but occasionally SEEK()
>>>
>>>>2) Do you think that SEEK must not be used in VFP applications?
>>>
>>>Refer to my comments above... SEEK is a powerfull tool that I use regularly when manipulating SQL result sets. The point here being that it operates on the results NOT the base tables.
>>>
>>>>
>>>>PS: I hope you understand that my experience with either C/S or client relations might be no less than yours.
>>>
>>>Never meant to imply otherwise.
>>
>>So, you retrieve recordset by SQL, then index it (or you have index on view?) and use SEEK within it? It seems to me as double work.
>
>Not at all. Consider a ad-hoc query capability that returns 200 rows to a grid so the user can find the exact record they want. On the click event of a column header I index and sort based on the control source of the column... Further, I can give users an incremental search capability.
>
>Could the same thing be accomplished using a SEEK, SCAN/ENDSCAN etc... Sure. This xBase approach starts to unravel (or at the very least become unnecessarily cumbersome in code) when the ad-hoc search involves conditions not represented within a single entity. Lets say the user wants to see the 'person' records where the last name starts with 'A', the company is 'IBM' or starts with 'INTERNATIONAL' and whose ship-to address is in TX. If the query returns 200 rows and they select the 1 they really want, retrieving the remaining person information using the PK in the person table is no problem at all.
>
>Mark

I suspected that you meant this isolated case of sortable grid. This still does not explain the whole thing. Your comparison is not presize. It's not necessary to use SCAN/ENDSCAN here, you may just use one isolated SEEK to get the record, does not matter is this part of recordset or table itself. You don't want to use SEEK against base table (let's assume this is your right), but doing differently you take double performance hit:
1) You SQL-retrieval itself will take time (non-comparable with one SEEK)
2) Indexing the recordset will also take time.
We're speaking about interface issue. Here, even 1 sec. delay to fill a grid is not a good thing. Obviously, everythig is relative: if client got used to 40-sec delays, and you give him 5-sec, it looks nice, but it's not 100% fair: VFP may and should provide instantenous grids.
This whole story is not about XBase against SQL, this oversimplifies and misleads. This story is about the simplest fact: SEEK() against base native table is the fastest way to get a record from this table. There are no rhetorics that could change this fact.