>There are somewhere around 120 fields in my view. It sounds like it is trying to update the view but I don't know what would be updating the view because I don't have any code in the destroy event of the form and when I run the debugger, I don't see any lines of code being run. It ends up at the read events line in the debugger when the error appears! Go figure!
<<

When a datasession destroys (which happens when a form destroys), it attempts to close all tables and view within it. This is done at the engine level, so it is not visible in the debugger, which just shows fox code executing. Since views are buffered and cannot be closed without tablereverting or tableupdating, it attempts to update the view.

The SQL too long message comes from the settings on the Update Criteria tab of the View Designer. Kamals suggestion will fix the problem, but let me tell you why it is happening:

Information on the Update Criteria tab determines the SQL UPDATE command issued when an attempt is made to commit the buffer.

For sake of example:
We have a view based on a table with a field called cid marked as the key field.
Row buffering is enabled.
We mark the fields cId, cFirstName, cLastName, and cPhone as updatable.
Before any modification to the record is made:
CID for the current record = "001"
cFirstName = "Kamal"
cLastName = "Patel"
cPhone = "555-1212"
We changed the field called cLastName from "Patel" to "Hodder"
We move off the row, so fox tries to commit the buffer.

If you have KeyFields only marked then the command that fox attempts to execute when committing the buffer is:

UPDATE cLastName WITH "Hodder" WHERE cid = "001"

If you have Key and Modified fields marked then the command fox attempts to execute is:

UPDATE cLastName WITH "Hodder" WHERE cid = "001" AND ;
cLastName = "Patel"

Notice that it only finds the records to update based on the key field and the fields in the row that were modified.

If you have key and updatable fields marked then the command fox attempts to execute is:

UPDATE cLastName WITH "Hodder" WHERE cid = "001" AND ;
cFirstName = "Kamal" AND ;
cLastName = "Patel" AND ;
cPhone = "555-1212"

Notice that it only finds the records to update based on the key field and the fields marked as updatable in the view, whether they were updated or not.

Imagine the size of the SQL UPDATE command that is generated for a view with 120 fields marked as updatable! Fox attempts to compile and run this command and chokes.

The safest is KeyFields only, because even though key and modified seems smaller, it approaches key and updatable with every field that is modified.
What you lose, is the ability for two transactions to update the same record at the same time as long as the two transactions update different sets of fields.

HTH