>>Beth,
>>I suggest you to reread OpenRowSet() sample. If you don't change anything but do a delete/add then your command turns out to be:
>>
>>delete from myTable where pkid in (select pkid from openrowset(...))
>>insert into myTable (select < fieldlist > from openrowset(...))
>>
>>or:
>>select * from openrowset(...) into table #temp
>>delete from myTable where pkid in (select pkid from #temp where action in ('change','delete'))
>>insert into myTable (select < fieldlist > from #temp where action in ('change','add'))
>>
>>Also search for "bulk/copy" here on UT and bcp/bulk insert in SQL server books online.
>>
>>Constraints and existing indexes might be a factor in slowdown. Bulk copy operations have hints (ie:default constraint checking is off). If you're doing insert/update/delete that'd affect multiple tables then consider doing them in a order that even if you turnoff constraints checking you'd not be beating integrity/concurrency.
>>
>>You might try with VFP remote views or updatable SPT cursors too if you can define a set to work on - you might well use openrowset() for that (table buffered if you try).
>>Cetin
>Hi, Cetin
> I do not use openrowset - mainly because I can not figure out if vfpoledb is on the computer I am using. Also, please see my reply to John Ryan on this thread.
>Thanks,
>Beth

Beth,
Your reply to John is rather cryptic. At least I could understand you were doing some sort of record by record operation, right? If so then it's expected to be slow.
It doesn't matter VFPOLEDB is installed or not and you don't want to use it. Please note that bulk/copy part has nothing to do with VFPOLEDB or ODBC drivers. You could create a text file and create temporary #temp from it (or OPENXML() with an XML file - IMHO would be slower).

RV or SPT also sounds to be faster ways than what you're doing (but again I couldn't understand it much).

Cetin