>I don't know though which is better, VFP or SQL.

I've often had this scenario in SQL:
- a c(10) field contains digits only
- one of the records was bad but someone wanted to keep it for some reason, so in that record we have a value of "100032 bad".
- there's a join with another table, from this field into an integer field, this works, unless...
- if the conditions filter out this record before it gets used in the join, it still works...
- if it gets used in the join... the whole 200 line SQL statement breaks with a critical "error trying to cast a character field as integer". There's no mention of any table, field, pk of the record where it happened, not to mention value which caused this, nothing.

It saved me dozens of hours when I stopped using SQL. And I couldn't fix the database, because the bad field was in the template database from which the test databases were derived, so no matter what I'd do, someone somewhere would pull up an old copy, run it through transformations and bingo, the old error was back.

In the most annoying queries I cast the integer field as char(10) collate database_Default and that was it. The last version of SQL which was so welcoming and forthcoming, not to mention verbose, was 2016, perhaps 2012, I wasn't really checking. Is it still like this?

Don't anybody say what val("100032 bad") or cast("100032 bad" as int) gives in Fox, or if you know, don't tell the SQL team. Let the users suffer.

p.s. just checked - postgres 10.13 returns a regular error, with the value of the first encountered field which can't be cast().