>>>Hi,
>>>
>>>I am troubleshooting a problem where the error log has many entries like this:
>>>

>>>12/30/2022 01:01:54 AM User: USERNAME. MethodName() Error: Numeric overflow. 
>>Data was lost. Value VIEW_NAME.PRINT_ORD: 3107
>>>

>>>
>>>The problem is that the field PRINT_ORD is an Integer type (accepts very large numbers). And from the error, above, the value is only 3107. Other values in the error log are all 4-digit numbers.
>>>
>>>How do I find out, from the TRY/CATCH which field actually causes the error numeric overflow?
>>
>>SQL server? Forget it. You may try with spanish inquisition, but I guess the tough guys from Redmond would never confess. Switch to postgres, there you get the field and the value.
>>
>>If you manage to talk with them, tell them that „data“ ARE plural.
>
>This is a MS SQL Server. I think before I switch to postgres, the customer will kick my ass. I am losing a lot of customers lately; not because of the SQL Server but because the competition offers something I don't have. I am guessing that what attracts customers to the competition is the Cloud. IT does not need to maintain a server and do the work. Then, they (IT) are surprised when their jobs go oversees.
>Thanks for confirming that it is a difficult problem to troubleshoot.

Is the error arising from trying to insert/update a VFP table/cursor, or from trying that on a SQL Server table?

Does your error logging process include the VFP call stack and the line number where the error occurred?

If it's ultimately a SQL Server error being reported via ODBC, what are the extended error properties? i.e. AERROR()