Hi terry,

>Thats a substancial increase in performance. How long were you twisting hairs before you increased the requery speed by 90%. Thats amazing!

Not too long, I was already familiar how Views were implemented and required access to the DBC. I was aware that there was a problem with locking (with remote views) and when I got these problems I knew that the definitions were read from the network again and again. I did some testing on making the database readonly so the oplocking mechanism could cache the database on the local workstation. This was a dramatic improvement. Now since the definitions of views, at least in our products, should be static, there was no objection to include that into the exe.

I must say that the view definition in question was one with a lots of fields in it and the SQL command was quite long. The 3 vs .3 seconds were on a 10 Mbps coax. On faster networks the difference might not be that significant.

Walter,

>>Hi terry,
>>
>>The slowness of RVs, in my case at least, seem to have to do with getting the RV definition from the VFP database. If it is on a shared network used by several users, it going to delays stuff esspecially on 10Mbps and slower networks. The SQL command send to the SQL server is just as fast as doing SPT as far as I could see.
>>
>>Therefore I decided a couple of years ago to include a database into the exe conaining the RVs. The same applies to local views as well. In one local view cases the time to do a requery() dropped from 3.2 seconds to 0.3 seconds.
>>
>>Walter,
>>
>>
>>>I don't use RV's. When I C/S, I use pass through (and SPs) - I have to do a little extra coding to assure sync, but the server's performance monitor sure seems to appreciate it.
>>>
>>>But - should I find cause - and I usually do - I will remember your kind and helpful words!:)
>>>
>>>>Terry,
>>>>
>>>>Put your RVs into the exe and it will be much and much faster.
>>>>
>>>>Walter,
>>>>
>>>>>Probably be good to have one that generates DataSets based on RVs too.
>>>>>RV consume so much resource and are so slow. They're great tools for analysis (tuning the project), but s l o o o w for a production system.
>>>>>
>>>>>We should shop for a technology to replace the RV - who knows how many VFP apps have been misperceived because RVs were implemented.