VFP error in production environment but not in development

There are a LOT of unknowns here but here is a guess.

when navigating from field to field

With the error:   operator/operand mismatch  --  Most likely it is not the 'navigating from field to field' that is generating the error, but instead some code which is executed either on entering the field or leaving the field.
Also with that type of error, there should be no difference between executing in a Development environment and in an Executable environment.    When you hit upon that precise sequence of events, the same error message should appear.

Unfortunately with that many fields in your Grid, apparently it is difficult for you to exactly duplicate what the user is doing.

First I would get the Users to describe SPECIFICALLY what they were doing when the error appeared (Precisely what field(s), what action, etc.)   With those specifics you should be able to easily duplicate the problem and find its resolution.

If, however that information is difficult to get and/or it will take a LONG time to get, you can begin to examine the various methods of the Form to see if there is some code which will 'not be happy' with certain types of field values and therefore throw that error message.

Good Luck

The main form contains 200+ fields of varying types

Another question I neglected to ask before is - are the 200+ fields always in the same data table/cursor.
The reason I ask is are the field types for each grid column ALWAYS the same?

If the data table being displayed in the grid were to change, then the field types for any given column displaying the 200+ fields might change and therefore the code on entering/on exiting the field might need to be 'flexible' so as to handle the differences.

If the data table being displayed was consistently the same table then the field types for the 200+ fields would be consistent.  

Inconsistent field types per column can be dealt with via 'flexible' code, but consistent field types makes it much easier.

Good Luck

To fix known error on unknown place in a large application is almost impossible.

Do you have error handling in your app?

You may put following code to the Error method in your form:

LPARAMETERS nError, cMethod, nLine
WAIT WINDOW TRANSFORM(nError) + "/" + cMethod + "/" + TRANSFORM(cLine) NOWAIT

Select allOpen in new window

Or instead of displaying the error info you may record it into a file together with other app status info. The error info will point to the line of code (you must compile with Debug info) and then you may decide about the fix. Don't forget to record the call stack (function ASTACKINFO).

If the above code does not trap the error then you have to create an error procedure in your main program and set ON ERROR to this procedure. The procedure can be very similar to the above Error method.

Thanks for replying. First of all, there is no grid involved - just a form with 200+ fields. The gotfocus event of each field stores the value of the field to a variable. The lostfocus event compares the last value of the field to the variable and creates counts accordingly.
The users claim that they merely click to one field from another. It seems that when the user navigates to a new field of a different type, it issues the error becauase it can't store the (new) field's value to the variable.
My solution would be to use a different variable for each field type. My problem is that I cannot force or replicate the error at all, so I won't even know if I've fixed the problem.....after changing the code for 200+ fields. I am able to click all over the place with no error messages.
The app has error handling, it is part of a framework and I don't want to change the error handling because of one form.
Thanks.

The app has error handling

OK, so what is the Error Handling reporting in detail (typically stored to an Error Log, an Error output file or somewhere else) as the location, type, etc. of the Error - not just the simple message that the user sees displayed.

I don't want to change the error handling because of one form.

If the current Error Handling isn't giving you the information that you need to get to the source of the problem, then maybe it NEEDS to be changed - not just to support one form, but to give you the information you might need to zero in on and resolve ANY problem.

Good Luck