ZConnection still connected after MySQL server stopped
Moderators: gto, cipto_kh, EgonHugeist
ZConnection still connected after MySQL server stopped
Hello!
I have a problem:
I use the latest ZeosDBO under Delphi 2005, with MySQL 4.1. I set everything properly, and my application runs properly.
But after I shot down the MySQL server, the ZConnection component is still in Connected := True state, so the AfterDisconnect procedure is not going to run.
What can I do to set Connected to false, after I shut down the MySQL server?
I have a problem:
I use the latest ZeosDBO under Delphi 2005, with MySQL 4.1. I set everything properly, and my application runs properly.
But after I shot down the MySQL server, the ZConnection component is still in Connected := True state, so the AfterDisconnect procedure is not going to run.
What can I do to set Connected to false, after I shut down the MySQL server?
I'm not shutting down the server manually...
For example I have two machines in different cities. First runs the MySQL server, and the other one runs my application. Let's say, that the first machine freezes, or something happens with it, so it needs to be restarted. Then the application on the other side won't know that the MySQL server stopped... And I think this is bad.
ADO (with MyODBC) sends an error message as soon as the MySQL server stopped, so something happens, when the server is stopped. Why Zeos can't give an error message?
I will not run a test query before my queries to check the avaliability of the MySQL server, because it would be completly a stupid thing...
For example I have two machines in different cities. First runs the MySQL server, and the other one runs my application. Let's say, that the first machine freezes, or something happens with it, so it needs to be restarted. Then the application on the other side won't know that the MySQL server stopped... And I think this is bad.
ADO (with MyODBC) sends an error message as soon as the MySQL server stopped, so something happens, when the server is stopped. Why Zeos can't give an error message?
I will not run a test query before my queries to check the avaliability of the MySQL server, because it would be completly a stupid thing...
It's also a stupid thing to have a server that freezes or needs to be restarted. Servers must be reliable machines. Don't get me wrong - it's just not good to build a system on fragile basis. All the SQL servers imply that the hardware is reliable and do use caching a lot - if the machine fails no one can guarantee that the data is saved or the tables aren't corrupted.
ADO does exactly the same thing as mentioned, because MySQL has no mechanisms for client notifying. Zeos han no such feature and the programmer need to write it by himself. Could be a MyODBC or ADO function, but not MySQL's.
Note that if the server is restarted, then the connection is usually automatically reconnected without errors (if the program is idle, on the first query it reconnects silently) - try if it works for you.
If you need the ADO fature, then I reccomend you to stick with ADO - it already has what you need and you wil not need to make changes in your application.
ADO does exactly the same thing as mentioned, because MySQL has no mechanisms for client notifying. Zeos han no such feature and the programmer need to write it by himself. Could be a MyODBC or ADO function, but not MySQL's.
Note that if the server is restarted, then the connection is usually automatically reconnected without errors (if the program is idle, on the first query it reconnects silently) - try if it works for you.
If you need the ADO fature, then I reccomend you to stick with ADO - it already has what you need and you wil not need to make changes in your application.
- mdaems
- Zeos Project Manager
- Posts: 2766
- Joined: 20.09.2005, 15:28
- Location: Brussels, Belgium
- Contact:
No that's not true. But the data beiing saved at the very moment the server crashes is lost indeed. However, all data that has been committed should be safe.
Also, there's a difference between the different table types you can choose from in MySQL. If you go for Innodb tables, those should be solid like a rock. Everything commited at the moment of crash is safe. All uncomplete transactions are lost. Using MyIsam tables, you don't have transactions and every statement is independent of the other statements. That means that there can be uncomplete operations if the crash happens in the middle of a series of updates.
Zippo, I fully support your vision!!
Mark
Also, there's a difference between the different table types you can choose from in MySQL. If you go for Innodb tables, those should be solid like a rock. Everything commited at the moment of crash is safe. All uncomplete transactions are lost. Using MyIsam tables, you don't have transactions and every statement is independent of the other statements. That means that there can be uncomplete operations if the crash happens in the middle of a series of updates.
Zippo, I fully support your vision!!
Mark