Mark,

I put a flashlight on numbers 2 and 3.

>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?

Unlike VFP, SQL Server fires the trigger once no matter how many row are modified by the UPDATE transaction. You wil have to place code to check the number of effected rows and then decide how to process them.

>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?

You have bumped into an interesting problem. The identity value is not assigned until the row is written back to SQL Server. Then you have no way to retreive the row w/o knowing the id (identity). SQL Server has a connection variable that contains the last identity assigned. Remember that this is scoped to the connection. If you update multiple rows in the same or different tables you'll get back only the last.

SQLEXEC(conneciton, "SELECT @@IDENTITY")

-Mike