× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I just have to vent a little here about MYSQL (free community edition) and the new, modern world we live in.

We are very small shop, and we have implemented the IAMP stack internally. Our main business use of our internal web site is to add and view image files. We also use it for lots of file inquiry, but we NEED it to scan, view and print image files (all documents in PDF format) every day. So no web site, no scanning/viewing/printing images. Business grinds to a halt, unhappy users, etc.

Last month we upgraded to the latest version of MYSQL 5.1.39 to get the IBMDB2I storage engine because we kept getting errors trying to load our data into SUGARCRM. The new version fixed the errors.

Last week we were working on another PHP application (moving data entry from green screen to PHP program on the web) and we simply needed to add a field to a MYSQL database. As usual, we used PHPMYADMIN, but this time it would not run correctly. Ok, we figure, something's wrong with PHPMYADMIN, let's use SQLCC. It runs, but will not allow any changes to the database. Hmmmm.


We tried to install new verion of phpmyadmin, got errors.
We then tried mysql_upgrade. Got errors.
We tried myslq_fix_privalege_table, got errors.
Shut down mysql, then tried mysql_upgrade.
Tried mysql_fix_privalege_table.
Started mysqld_safe, got errror "could not remove old PID file".
We tried to delete PID file with OPSNAV, could not because it was in use.
We changed my.cnf to use new pid file. Got error device busy.
Shut down apache, all HTTP servers, all subsystems we thought could be remotely connected to this problem. We could not delete the PID File MYSQL wanted to recreate.
We called IBM to ask how to delete PID file in IFS. AS/Navigator properties could not show what job was using it, so IBM recommeded IPL of AS400.
We restared the as400. IT took 45 minutes, but after it came up, MYSQL worked just fine. Total elapsed time from start of problem to resolution, 6 hours.


I am just amazed that I had to resort to a PC tactic of re-booting to fix things. I guess if you're using PC type tools, you need PC type fixes.

While searching the web for possible solutions, we came across many suggestions. Each involved changing some arcane setting somewhere in MYSQL config files. Lots of stuff that I had a hard time understand what the suggestion would do, and where the heck to find it. "go look at yetanother.cnf in the etc/bin/usr/notthatusr/theotherusr" or the "outie.ini in the /local/express/metro/nonstop" or some other deeply nested directory. "Remove the 3rd comma and # from the 2nd line."

Anyway, I am assuming that people that run their entire business on a LAMP stack put up with all this crap. No wonder they need a system administrator. I have enough work getting my applications to do what I want, I don't want to have to know all the ins and outs of MYSQL or APACHE. Geez, imagine the as400 database not working.

The sad thing is we know the as400 (I, Iseries, whatever) is a better way but IBM is doing it's best to keep it a secret.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.