Is there an active index on the VFP cursor? If so, that may be slowing you down because the TABLEUPDATE() cycles through the cursor but it also has to be aware of the index.

You might also want to check what the Transactions setting of your SQL connection is set to. I think if it is 1 - Auto (Default) then each record that needs to be updated has its own implicit BEGIN/END TRANSACTION. Set the property to 2 - Manual. Issue your own BEGIN TRANSACTION to SQL Server, Tableupdate() and issue a COMMIT TRANSACTION.

Just my $0.02.

>First of all, I´m using VFP as the front end.
>
>=SQLEXEC("Select * from MyTable where MyTable.Field1=?MyCondition","MyView")
>will return a cursor, which with a few addittional commands can be made updateable, and act much like a remote view.
>
>I then index this cursor locally, so that I later may ask something like
>this
>
>Program loop....
>...
>..
>

>IF NOT SEEK(SearchKey,"MyView","Key1")
>   INSERT INTO MyView...
>ELSE
>   REPLACE MyView.CalculatedField WITH AnotherValue
>ENDIF
>

>...
>..
>End loop....
>Issuing a TABLEUPDATE()the data are written to the server, and this is where the trouble begins.
>
>In short, what´s taking it so long, and what can I do to speed things up?
>
>The write operation to the server takes more than twice as long as writing to DBF style tables on a file server.
>
>And it makes no difference if I issue the update once for the entire cursor or one record at the time.
>
>Now, there is a clustered PK, but still...
>
>Does SQL 7.0 write to a transaction log during this task?
>And is there a way to turn the logging off?