Michel IMO the best thing to do is to have that inside a try catch statment where in the catch stament what I would do is to log the oparameter.count and also the ocommand.parameters.count so see if they are diferent.

>>base on the call stack I would agree with Bonnie, Michel is the ocommand created only on that method is is a shared object?
>>Also oparameters is that a local variable or a property of the class?
>>is that class shared between diferent objects?
>
>oCommand is a property of the class. Everything that is local includes the scope in front such as loCommand.
>
>oParameters is a property of the class. oParameters is clear after each request in case the same object would issue another request. When this would be the case, it means oParameters is Nothing unless specified otherwise such as defined here where I set up two parameters.
>
>The data class, in that particular hit, is assigned to several objects such as loDataProviderClient, loDataProviderInvoice and loDataProviderCountry. Usually, one object is responsible for doing one SQL. So, when we rely on loDataProviderClient, we can easily see that this instance of the data class is about querying against the Client.dbf table. But, even if I reissue another SQL request on the same instance, this has never caused me a problem so far.