Re: MySQL Error: 0 (FIX THAT WORKS - NO REGEDIT NEEDED)!
First, that is not a fix, it is a workaround. Second, since you will lose all of your databases this way, it is not a good idea on a production server in an environment where you need to recover your databases, such as a commercial environment.
If the Registry ever needs to be fixed, for any program, then that qualifies the problem as an actual bug.
If the service won't start, for example, because of Error 1053, it may be deferred to the reason that Windows only allows a too short of time for the service to start, however, that is the compile and configuration of MySQL's fault, not the fault of the operating system. It basically says that MySQL does not comply with Microsoft Compatibility Standards and that the developers should make it comply.
There is a fix for this timing problem on this forum, somewhere, but finding it is difficult, at best, because the known fixes are not listed in any area in any organized form.
However MySQL is compiled, it should account for operating system requirements, in this case, critical timing. There are only two critical timings, endless loop and discontinuity. The MySQL problem is of type discontinuity.
Because programming standards require that no process be allowed to endlessly wait for some event, a cap is put on the amount of time a process can have to complete successfully. But when that cap is too short, the second type of timing problem, discontinuity, causes the process to terminate prematurely because the operating system believes the process is in an endless loop. An endless loop often takes up 100% cputime, effectively bringing the computer system to an effective halt in processing all other processes.
It is in determining the time allowed for a process to start and finish that the program fails to adhere. Basically, the program compiled does not know the proper amount of time to allocate for starting a service, that is, where it will get to the point where it can tell the operating system that it has finished initialization and is now running as a service which may be then set to a terminate and stay resident state. This is simply a wait queue state which does not abuse system resources.
The operating system itself is an approved and allowed endless loop, but because it's subprocesses are monitored it is not terminated, ever, except upon system shut down and/or system shut off.
Services enjoy the endless loop privilege if and only if they properly report to the operating system in a timely manner and do not consume excessive system resources [anything over 70% of cputime and more ideally less than 50%]. Lateness begets termination and excessive time consumption and resource consumption begets terminate with dump.
If terminate with dump and developer's debug mode is not running, the report will be a simple error report with number, such as Error 1053 and some brief description of the reason for termination.
Often, the developer's or operating system description is too broad and general, or second level [meaning it doesn't report the actual problem, but a secondary symptom and/or cause].
While the MySQL developers have, it seems, listed the Error Codes in a somewhat meaningful way in documentation, there is not an accompanying link to a log of known causes and solutions per error code number.
Thus, one spends the same amount of time as the original people who had a problem and fixed it in searching for the known solution.
In designing systems we keep two logs: Design Change Notice and Engineering Change Notice [DCN and ECN respectively].
We cross reference each by Error Code so that we can return to previously researched and extremely valuable information should similar errors, by the numbers, reoccur.
It is more important to cross reference the solutions by the Error Number first so that any search will present a list of all known problems and solutions for that Error Code Number. Particularly for the Solutions Set which should be presented first, before the discussion of the causes.
This forum does not currently do that, instead presenting a non-sorted result based on description alone. This means you have to manually sort all solutions [read them] which takes considerably longer time than sort by solution number=error code number.
A selection of solutions by error code should be selectible over solutions by description.
Principally, the problem is in the Registry, because of improper installation at the developers level, therefore, the solution is in the Registry as is the workaround or fix [patch be it manual or automated].
The "reinstall and it worked" is a misnomer, since most reinstalls lose critical data and databases, users and passwords, in short, access and integrity.
The problem is in: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MySQL\
The variables set there are incompatible with Windows systems.
Second, it has been observed that MySQL installs erroneously start to put this key in: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
the outerblock of that Registry ControlSet, where no key belongs.
Either a manual fix or a programmatic fix is in order, not a reinstall.
And this presented fix is technically a bad fix, since it causes the loss of both data and connectivity, particularly to other programs such as the MySQLAdministrator, phpMyAdmin, and many others.
This forum itself, a scripting application dependent upon Perl and PHP and an integral database, would fail such a reinstall with loss of all data and users.
Similar forum software is SMF, phpBB2, vBulletin, and MySpace type bloggers and content streamers.
These are all used in commercial environments and the loss due to reinstallation is costly. It may, in fact, end the commerce.
The workaround you provide, suggested many times by MySQL developers, is not a very good one. If you reinstall by removing all traces of the previous MySQL, you will lose all databases and users and you will not then, because of security connectors, be able to recover backed up databases and users because you do not have the proper keys and passwords stored in those database.
Which means you will have to rebuild the entire database and all users manually.
In short, your company will have to start all over again.
Not a very good advertisement for what the promoters are calling the best database engine; this failure makes it the worst.
Regardless of protests to the contrary by the developers.
Secondly, I have presented many solutions to MySQL problems and continue to work on it. As with any other friend, user, or customer, I would expect a modicum of respect for that effort and not a dismissal with the short and trite reply "This is not a bug." Espcially from those with 30 years' less experience.
That is simply dismanagement among the developers.
Other developers who have take a similar tac include KDE and recent developer arrivals in the Linux community. Microsoft, in complete contrast, listens to every complaint and solves its software problems for its customers without offending them.
Perhaps developers should listen to the most successful company and implement their company policies among employees.
And that first requirement is, like J.C. Penny said, "The customer is never wrong."
This is a bug.
Subject
Written By
Posted
February 07, 2005 08:47AM
September 12, 2005 01:59PM
November 08, 2004 12:01PM
November 02, 2004 04:23AM
November 08, 2004 02:14PM
November 08, 2004 03:23PM
November 09, 2004 01:14PM
November 14, 2004 07:28PM
February 19, 2009 12:28PM
December 05, 2008 10:07PM
February 24, 2010 04:18AM
February 17, 2010 11:22AM
September 01, 2005 01:25PM
Re: MySQL Error: 0 (FIX THAT WORKS - NO REGEDIT NEEDED)!
October 08, 2006 11:00PM
November 10, 2006 01:12PM
November 06, 2006 05:36PM
November 02, 2007 12:55PM
December 27, 2007 08:55PM
February 07, 2008 04:57PM
September 11, 2008 12:19AM
September 12, 2005 02:12PM
November 05, 2004 01:48PM
November 07, 2004 08:09PM
November 08, 2004 11:52AM
November 10, 2004 09:44AM
November 26, 2004 03:37PM
December 01, 2004 05:18PM
November 26, 2004 03:39PM
December 22, 2004 12:28PM
December 22, 2004 12:31PM
November 13, 2004 10:14PM
November 18, 2004 05:24PM
November 26, 2004 03:27PM
November 29, 2004 03:55PM
November 30, 2004 10:27AM
December 22, 2004 10:30AM
February 27, 2005 01:55PM
February 27, 2005 02:09PM
February 13, 2005 12:16PM
September 11, 2005 08:56PM
November 19, 2006 11:13PM
September 11, 2008 12:23AM
February 08, 2009 04:36AM
February 27, 2009 10:06AM
February 28, 2009 01:28PM
September 04, 2009 09:09AM
November 23, 2009 11:33AM
September 02, 2009 10:55PM
November 25, 2009 05:47AM