Bob,

Thanks for the suggestions! In the meantime I discovered that the problem is entirely due to a trigger. I had mistakenly thought that I had turned off the trigger to rule it out as a cause - but it was actually still running. See my (Message#681420) in this thread

I will definitely check out the sql performance site. As you see in the other message, I am now trying to determine what components of the trigger make it so slow, and how it can be sped up, and/or selectively turned on or off.




>Remember,
>
>With SQL you have a fault tollerant and automatic transaction. Are you using a transaction in VFP?
>
>Try running the update with VFP and turn off the machine, how is your table?
>
>Now, try the same with SQL Server (if the server is remote you get better results.)
>
>Since you are comparing apples and oranges it's not a fair test. Is the CPU, memory and diskspace/speed the same, sure it is. Well, SQL uses much more resources, so on the same machine you should get better performance from VFP. That is in addition to the fault tolerant features mentioned.
>
>Now to some tunning issues:
>
>Is cCustNo the PK? Is is the key you most often use to access this data? If so, it should be the clustered index. What is the fill factor of the table set to?
>
>What about triggers? Is there an update trigger on the table?
>
>>I tried this. It suggests that an index on ccustno would improve performance by 10% - if I understood the recommendation correctly. Let me also say that there are about 7 or 8 existing indexes - this is not a database I created. Maybe getting rid of them would improve performance. But I can't believe we are talking 'orders of magnitude' here. The select performance is roughly equivalent - but updating - forget about it.
>>
>
>Yes, you may want to figure out the need for all the indexes. As has been said here, the more indicies the slower updates take.
>
>Also, you may want to take a look at http://www.sql-server-performance.com/ for some more info.
>
>BOb