>>>12/30/2022 01:01:54 AM User: USERNAME. MethodName() Error: Numeric overflow.
>>>Data was lost. Value VIEW_NAME.PRINT_ORD: 3107
>
>I think that's VFP error 39: "A mathematical operation resulted in a number that was too large to be stored in the field or variable in which it was placed."
>
>This is most often seen when SELECT includes an expression field. The field size in the resulting cursor is determined by the first row.
>
>Example:
>

create cursor c_source (print_ord i)
>insert into c_source values (0)
>insert into c_source values (1000)
>select iif(print_ord<1,1,print_ord) as print_ord from c_source into cursor mytest readwrite
>browse

>
>Row 2 shows * numeric overflow- because vfp deduces that the 1 returned by the first row's expression is N(1) which then determines the size of the field. If you now do something like
>
>

replace print_ord with 20 record 1

>
>You'll see error 39.
>
>There's a few ways to prevent this, e.g. use CAST to force the expression to return an appropriate size.
>

select iif(print_ord<1,cast(1 as I),print_ord) as print_ord from c_source into cursor mytest2
>brow

>
>You can also see this if people rely on something like INT(0) to create an extra integer field:
>

select *,int(0) as extra from c_source into cursor mytest4 readwrite
>replace extra with 10 record 1

>
>Even though the extra field's expression appears to force an integer, VFP still does its own thing on field size.
>
>My pick would be that the destination cursor has a N(3) or less field size set somewhere along the way, so that replacing with a 4-digit print_ord causes error 39.

Thank you for the detailed message. In my case, there is no SQL Select. One cursor updates another cursor. But you may have a point that the cursor being updated has a smaller size field. I will double check.