>I am writing a pretty large application using SQL Server 6.5 and VFP 5.0a.
>I have written many multiuser applications in FoxPro 2.6 and VFP, but this is my first
>attempt using a combination of VFP and SQL Server. My locking code works fine with
>native VFP tables, but when I upsized them to SQL Server I am running into several
>problems. This is the problem:
>
>1. If I include a timestamp field in my remote view (not checked as updatable), the
>timestamp doesn't update on my view when I make changes. This causes SQL Server
>to think a conflict has occurred when I attempt to update the same record more
>than once without requerying the view. I don't want to requery the view since I
>am dealing with a bunch of records (over 100,000).
>
>2. If an update conflict occurs, my SQL Server triggers fire anyways. I have my foreign
>key logic built into my update and insert triggers, but I wouldn't expect those routines
>to fire if an update conflict has occurred. What test can I do to stop this?
>
>3. I have several identity columns that are not updatable in the remote view. Without
>requerying the view, how do I refresh the identity column?
>
>Besides these issues, I must say VFP/SQL Server is a great combination. Can anyone
>put some light on these problems? Much appreciated. RJC

You don't mean that you are handling 100k records on the client side, do you? Your result set of rows returned to the client should be fairly limited. The only way I know to refresh data is through a requery. Requery should be quick enough if tables on the server are indexed properly, SQL statements are already optimized, etc. One key to optimizing SQL statements is to make sure the case is always the same -- Select * from ... is interpreted as a different statement as SELECT * FROM ... At least from my experiences in Oracle, if a case-identical SQL statement has already been submitted, requeries go faster.

I also do not think you can just refresh single columns without requerying the entire view.