Check if Param assigned

[NickNevzorov]

Access violation in my case

[marsupilami79]

Hello Nick,

how do you create this error? It is highly unusual that a param is not assigned. I assume, your patch only hides an other problem.

Best regards,

Jan

[NickNevzorov]

My application executes multiple parallel threads with short queries to the database.

In case of empty SQL text I have error with reusing ZTQuery, thats causes executing wrong stetement and access violation in InternalPrepare.

This code is unsafe, Params.FindParam(ParamNamesArray[I]) can be a nil. Additional check allow me to find a real reason i code and prevent for execptions in a future with another problems

[marsupilami79]

My application executes multiple parallel threads with short queries to the database.

I hope, you have a separate connection per thread? It is only safe to use Zeos in threaded environments if you have one Zeos connection for each thread.

In case of empty SQL text I have error with reusing ZTQuery, thats causes executing wrong stetement and access violation in InternalPrepare.

This code is unsafe, Params.FindParam(ParamNamesArray[I]) can be a nil. Additional check allow me to find a real reason i code and prevent for execptions in a future with another problems

Ok, I will rephrase what happens here: From my POV Param must not be empty. If Param is empty at that place, it means something went wrong. The expectation is that when an SQL statement ist assigned, all Param objects will get created automatically. If they are not created, most possibly something bad happened.
Your patch will only hide this condition. This is why I asked for an example on how to reproduce this error. Right now the only thing I can agree to, is to raise an error if Param is empty, so no access violation is generated.

[NickNevzorov]

I hope, you have a separate connection per thread? It is only safe to use Zeos in threaded environments if you have one Zeos connection for each thread.

Yes, one Connection and one Query per thread. But I using my own connection pool of TZConnections and TZQuery, each new thread reusing old TZConnection and TZQuery

Your patch will only hide this condition.

I agree, my patch add unnesusary check if all working fine. But if You have another problem, and when SQL statement is assigned, but Param objects does not creates as expected, You get an exception and hides real problem in app

I'm sure this code will work fine without changes. But it's potentially a bug, a nil check is needed in such code.

In my case it hides another exception, and I spent much more time looking for the real problem than I should have.