>>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.