>But did the message originate from the VFPOLEDB?
Yes
>The fact that it was expecting a 'ADDDATE' variable should provide a clue - presumably such a variable or column name is used in the App.
Well, I have about 1000 fields in the application across 84 tables. And, I would say I mainly got them all in those errors. Basically, the errors are totally not related to the actual SQL commands. As most of the fields are used in the overall set of SQL commands of the application, when a field is reported, it could come from what was accessed before. This is really weird to me. Sometimes, a field name is mentioned in the error message and that field was used like 20 minutes ago the last time based on the list of hits that was done in the last 20 minutes.
> Just a thought: if you change the namespace for your page based classes you might be able to discover where they're used/referenced by the global class/classes from the resulting compile errors.....
I am not sure what you mean.
>Can't think of much else to suggest - essentially the interaction between your application object and the hit instantiated object (oProcess?) should be limited to the reading of oApp properties by oProcess. Anything else should be viewed the suspicion.....
Well, I use oApp for the global application properties as well as calling methods in it that are global to the application. All methods that are Web specific are in the LXProcess class knowned as oProcess when the object is instantiated. So, basically, methods like these:
Public Function GetDate(ByVal tdDate As Date) As String
Return Format(tdDate, "dd/MM/yyyy")
End Function
Public Function GetDateTime(ByVal ttDateTime As DateTime) As String
Return Format(ttDateTime, "dd/MM/yyyy HH:mm:ss")
End Function
are called directly from oProcess.oApp.GetDate() and oProcess.oApp.GetDateTime(). Those are not specific to the Web process so they remained in the oApp level.