When several clients are browsing remote views [some guy told me this], record updates may slow performance. Clients may need to wait out a refresh for changes made to tables. I have heard that remote views can get slugish in high traffic. I'v also heard, but didn't mention, that stored procedures will also cut a few ticks off the clock.

I should have limited my remarks to overall network performance and record level I/O. Since pass through views are local, changes made to the PT view and subsequent calls to backend procedures to up date the tables would not [necessiarly] have to push a view refresh as it would in the case of a remote view, where the client is bound [i'm not a sql scientist!] to a live table. At least it's been proposed to me that way :-).

Stored procedures are also good [at least that was proposed], especially if the server tools make it easy to set them up.

But working with paremterized views and indexing is good advice anytime, with any kind of data system!

I have no idea whatsoever on the query execution times. It seems that PT may use additional clock to build and manage the cursor. Most SQL queries are fast. But none of em are up to VFP. VFP is fast!! Especially if the projects are structured and optimized for speed. Like hotrodding a hot rod!

At least thats what I've heard.

>The execution time of the query to the database shouldn't be any slower whether it's sent by Sequel Pass Through (SPT) or prepared by a view and sent by VFP. Any difference in speed would be due primarily to the requirement that VFP has to read the view definition from the VFP database.
>
>Having said that, you should only be using views when you want to update a small number of records. If you're pulling data across just to get the info (for reports, lookups, etc.) you should use SPT.
>
>Whether you're using a view or SPT, you need to make sure that you're only bringing the fields you need. Bringing 50 fields across the network (by using SELECT *) when you only need 5 will take approximately ten times as long.
>
>Limiting the view or SPT query to only the fields you need and having the appropriate indexes set up on the Server should be an improvement over a VFP database. I routinely bring down 10,000 records from a million record SQL Server table in under a second.
>
>P.S. You also never want to select all of the fields in a view if you can help it. If you do this and the underlying table structure is changed, the view will become invalid. This isn't an issue if you select at least one less field in the view than there is in the table.
>
>
>
>>Remote views are slow. Pass through cursors are fast - but there is some >code overhead to manage database updates. Parametrized should speed either >up - but you'll get a better approximation of rushmore by using pass >through.
>
>
>>>Hi all, I am trying to migrate data an app to sqlserver, also have made test with progress rdbms, but there is a customer table with aprox 52,000 records, I am building a parametrized view to access sqlserver data for column name (i have an index in sqlserver for that column) but even with that it takes some time to retrieve data, far more that with Visual FoxPro, also have tried select * from customer where cust_id="100022" (direct to Primary key) but feel it kind of slow.
>>>
>>>What this because I was used to Visual FoxPro perfomance ?, I have made similar tasks with MYSQL backend with fast response also.
>>>
>>>Thanks for any feedback
>>>
>>>
>>>Norman