I am referring to doing a TABLEUPDATE to modify SQL Server data. This requires more than row/table buffering. It either requires RVs or executing several CURSORSETPROPs to make a cursor updatable. We tried both techniques and didn't like the results of either.

But the reason which tipped the scale over to writing our own routine was because our SQL Server database has unicode data types. This reason in itself is enough to merit writing a routine over TABLEUPDATE. TABLEUPDATE simply does not update SQL unicode data types properly. I don't think it is the TABLEUPDATE statement itself, but somewhere between the time you do the TABLEUPDATE and the time the SQL database actuallys gets updated a CHR(0) gets appended to the end of the field, and a side effect of that is padded spaces. For example...if I have a SQL column defined as NVARCHAR(50) and I store "Microsoft" into a Remote View and then do a TABLEUPDATE, the SQL column will be padded with 40 spaces and a CHR(0) at the end of Microsoft, which defeats the purpose of the 'VAR' in NVARCHAR. If you take that same field and execute SQLEXEC('UPDATE table SET column = 'Microsoft'), this statement works just fine.

After trying all possibilities we concluded our best option was to write our own routine which dynamically creates the SQL INSERT, UPDATE, and DELETE statements.

SIDE NOTE: We looked into using ADO which would have worked also, but we wanted to be able to use VFP cursors without doing an RecordSet2Cursor conversion.

(Sorry for the long explanation...I'm a wordy kinda person <s>)
GeneS

P.S. SCATTER/GATHER? Whats that? <s>



>Why would you bother doing that?
>
>First of all, TABLEUPDATE() does not require the use of RVs. It requires row/table buffering of tables/cursors.
>
>You must not be using row/table buffering. Please don't tell me you are using SCATTER/GATHER.
>
>
>>We wrote a routine which mimics the TABLEUPDATE (because we are not using RV's). What we found was that if varied. The smaller the set of updates, the faster our routine was over TABLEUPDATE. When you got into updating thousands of rows, the TABLEUPDATE became faster.