>It is still there.
>
>Our latest message this morning is:
>
>

>Variable 'ADDDATE' is not found.
>
>SELECT MasterType.* FROM MasterType
>

>
>This shows clearly that there is really something mixed up in the memory of the data provider either in the way the class is managed or at the connection level.
>
>The only thing I could see that could be in effect would be a parameterized setup that I could have done wrong. When there is a error in the data class, I am showing the oParameters collection items. But, instead of that, I will show the parameters coming in directly form oCommand.Parameters just to be sure this one is clean as well. But, that would surprise me there would be a garbage issue here in the parameter collection. As you can see here, I am always clearing it up, just to be sure, before adding the new set of parameters, if any, before doing the SQL:
>
>

>                ' Only add the parameters if we have some
>                oCommand.Parameters.Clear()
>                If oParameters2.Count > 0 Then
>                    For Each oDataParameter In oParameters2
>                        oCommand.Parameters.Add(oDataParameter)
>                    Next
>                End If
>

If oCommand is scoped to the hit (and only referenced within that scope) then the parameter collection should be clean. But what's the scope of oParameters2 and how is it populated?

But, IAC, since the SELECT doesn't make use of parameters in this instance then an invalid parameter collection shouldn't cause the error.

Is MasterType a table or a view?

Where did the "Variable 'ADDDATE' is not found" message come from - .NET or VFP?

Can you put a try/catch just around some of these error points and simply STOP in the catch. The debugger might then provide clues to what goes wrong...