Zeoslib Portal

aehimself wrote:

DavideAmelio wrote:libmySQL51.dll

Upgrade. Quickly See here.

Seem stupid but i can't find the .dll !

DavideAmelio wrote:Of course i have a timer that ping each minute...

Do you disable the timer when you pass the connection to an other form and do something else on it? Remember, one connection can do one thing at a time. If you have a query running on the secondary form and the timer on the first form pings, the query on the secondary form will fail with the very message you try to avoid.

No, I never disable timer, each works by itself, but why in WinXp / Win7 / WinServer no errors and problems? Only if i use the same application on Win10...few minutes and "Mysql as gone away...."

DavideAmelio wrote:About doing more query at the same time with the same connection...could be, So I have to use different connection on each form?

Well, yes, and no - that depends on what your application is doing. I am using only one connection in my database client application which has 4 modal popups for specific tasks, and it works well. But I'm really careful to pay attention to the multithreading best practices.

I Always Known that Datamodule is for this, infact I put ZCon and some ZQry, the other zQry will build and destroy at runtime...each one pointing the same zQry.connection ( now abstract )

DavideAmelio wrote:Seem stupid but i can't find the .dll !

The forum post just shows you WHY you should upgrade, not HOW Depending on your choice (libmysql / libmariadb) the process of downloading them is different, Google is your friend. You'll need the C connectors.

DavideAmelio wrote:No, I never disable timer, each works by itself, but why in WinXp / Win7 / WinServer no errors and problems? Only if i use the same application on Win10...few minutes and "Mysql as gone away...."

Sheer luck, it just didn't seem to happen at the same time. As I mentioned earlier - I experienced exactly the same when creating my DB client. When I disabled the timer before opening the modal window, the issue disappeared.
You can write multithreaded applications without any synchronization or critical sections and it will work for a while before crashing; but just because it's running for a day or two it doesn't mean that the code is correct.

DavideAmelio wrote:I Always Known that Datamodule is for this, infact I put ZCon and some ZQry, the other zQry will build and destroy at runtime...each one pointing the same zQry.connection ( now abstract )

No, as far as I know (I never used them until now) a datamodule is just a separate place for you to store your data access components; thus decluttering your main form and allowing to separate data access methods from UI's source. It's nothing else but an invisible "form". What you do and when you do that with your components on the datamodule is up to you only, therefore you are responsible for serializing your requests.

aehimself wrote:As I mentioned earlier - I experienced exactly the same when creating my DB client. When I disabled the timer before opening the modal window, the issue disappeared.

That seems strange to me. Usually timers should not get fired in a separate thread. They use the windows event queue. So even using timers, there should be no probelm. Just for my interest - could you produce a minimum working example that shows that problem? Or did you use another timer implementation that fired timere events in a separate thread or something like that?

Best regards,

Jan

marsupilami wrote: ↑22.11.2019, 10:09That seems strange to me. Usually timers should not get fired in a separate thread. They use the windows event queue. So even using timers, there should be no probelm. Just for my interest - could you produce a minimum working example that shows that problem? Or did you use another timer implementation that fired timere events in a separate thread or something like that?

In theory you are right, Delphi TTimer timer works with window messages and message queues are not processed during blocking operations (hence the freezing of forms). Since I don't remember the last time I used blocking operations in the VCL thread it's possible that my experience is not from a standard scenario. Even though, it's never enough to stress to keep thread safety!!!

I'll try to reproduce the symptom without workers. If I do not reply, it means I could not

hello, only for sharing experience : After rewriting all my Db Library function for accepting "AbstractConnection" the problem was still there, However I rewrite ( again ) passing the TZConnection, and changed all calling from source code with _DataModulde.zConection instead Qry.Connection....Works!! I Dont'w why....maybe whene some Qry is Detroyed the Connection is destroyed too......However thanks for your time.

Hello, only for experience sharing: I rewrote all DB Libs for accepting AbstractConnection instead ZConnection, but the problem still was there. Then I rewrote again accepting ZConnection and rewrote all source for calling function Datamodule.zConnection instead of Query.Connection...WORKS!! I Dont know why---maybe destroyng some Qry the connection is automatically closed ?
However thankyou for you time