>That's an intereting idea; had not thought along these lines.
>
>Ironically, the 'serial_no' field being chosen in the initial SELECT statement from the SERHIST table is already a VarChar so casting that field would obviously be self defeating and would not work.

Remember that when you open a remote view in VFP, you're actually creating a local VFP cursor with VFP columns. Just because the source column in SQL Server is varchar doesn't necessarily mean the mapped column in the VFP cursor will be varchar as well. VFP9 is supposed to interact better with SQL Server than other versions so by default a SQL Server varchar column might get mapped to a VFP varchar cursor column, but it would be worth checking. I don't know the answer off the top of my head. But, if it isn't being mapped to VFP varchar, you could force it using the CAST() in my earlier message.

>
>However - it would be worth trying casting the result of the update source data instead of ALLTRIMing it.
>
>The update shown in this script is convoluted as shown because the objective is to increase an existing character 'number' by a specific numeric value. Hence the intial character number value has first to be converted to an equivalent real numeric value; then add the numeric increment of 341; then return this new numeric value to an equivalent character value without any decimal places, hence the INT conversion component in the code as shown in the original question.
>
>So, based upon your suggestion I could try:
>

>SET serial_no = CAST((INT(VAL(serial_no)) + 341) AS VarChar ( SQLColVarCharWidth ) ) ;
>
>

>as an option and see what happens.

Sure, that's worth a try as well, or instead. Bear in mind that for this to work, the local VFP cursor column might need to be varchar, so you may need to check it or force (CAST()) it as detailed above.