MySQL Forums
Forum List  »  Install & Repo

Re: MySQL Error: 0 (FIX THAT WORKS - NO REGEDIT NEEDED)!
Posted by: Terry James
Date: October 08, 2006 11:00PM

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.

Options: ReplyQuote


Subject
Written By
Posted
March 26, 2009 06:32PM
April 28, 2009 09:16AM
June 05, 2009 08:59AM
January 19, 2005 09:57AM
August 16, 2007 10:20AM
August 19, 2007 08:57PM
December 05, 2008 10:07PM
April 26, 2009 05:29PM
August 15, 2009 07:47AM
August 30, 2008 11:22AM
Re: MySQL Error: 0 (FIX THAT WORKS - NO REGEDIT NEEDED)!
October 08, 2006 11:00PM
my
November 18, 2004 05:24PM
February 27, 2005 01:55PM
July 01, 2009 05:46AM
July 01, 2009 03:41PM
July 01, 2009 05:08PM
July 01, 2009 11:52PM
July 09, 2009 02:07AM
July 21, 2009 10:49PM
C S
September 04, 2009 09:09AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.