>>I agree with the others that you want to get everything in shape before appending to SQL Server. In your shoes I'd use SELECT expressions into a new cursor, eg
>>
>>

select EVL(DateTimeColX,.NULL.) as DateTimeColX, ...

>>
>>(but watch out if the very first value is blank or VFP will throw a "cannot determne field type" error)
>>
>>and then append from that cursor. Also, if rows are safe I'd look at the tablebuffering since SQL Server needs lots of room for database log if it's all one fat append.

I still think creating an ASCII file to bulk import with the SQL select John describes (via "to" clause) will import minimally faster ;-))


>Yes, doing any datamunging ahead of upload to SQL Server is definitely the way to go. For some reason I thought that a tablebuffered remote view would act like a local cursor until TABLEUPDATE() was applied (i.e. not involve the backend). Clearly that's not the case.
>
>Per your suggestion about table buffering, I switched the RVs to use optimistic row buffering (=3) instead of the default optimistic table buffering (=5). AFAIK those are the only two settings that are valid for RVs.
>
>Results:
>
>- Table buffering: 7:49
>- Row buffering: 8:07
>
>Those results are well within the normal variance so for this scenario I don't think that setting is making any difference.

for curiosity sake, try cursoradapter once, if not too busy. And if showing similar times, try to detach/attach the cursor ;-))

//upd: another idea might be to close the connection: I know one home grwn fwk, where CA are used all over but connection might be closed depending on settings ffor the app, with checking/reestablishing in a hook - might be a way to isolate a RV as well ;-))

regds

thomas