Re: was database too old or corrupt error on debian ever solved

Dan O'Donnell writes:
 > While agreeing with Rich, I think this specific case the solution would
 > be to add a line to the troubleshooting page, since it is a recurring
 > problem, and we have similar specific and common error messages already
 > listed there. Basically two lines, one saying: "Main Database to Old or
 > Corrupt": the most likely cause of this error is a faulty setting in the
 > config. files. Check that you have indicated the correct database in
 > file xxx; and also that you have changed the user name in xxxx."
 > 

I've added a few lines about the database too old or corrupt
error. The username/password stuff is already explained in that
section as it causes a different kind of error message.

 > I also think there should be an indication that the desired dbase system
 > needs to be set in the config files, otherwise the default is SqlLite.
 > 

This is already described in the manual as well as in the ./configure
--help output (but it is a known fact that users don't read. I'm not
complaining here, it is just a fact we have to live with and work
around if possible).

 > Finally, I wonder if supplying values for dbase and username in the
 > config files is really wise, especially in the case of the dbase
 > username (nobody is likely to use Joe User, so this can ONLY cause
 > trouble), and probably in the case of SqlLite, since many people will
 > want to use either MySql or PostGres.
 > 

This is basically a good point. The clients are written to
use the login name as a fallback if no database user name is
supplied. I'll change the config files accordingly.

 > A better approach IMO would be to use a script to ask users for the
 > username and dbase server type (the way mediawiki do for username);
 > failing that leaving them blank and *requiring* users to fill in the
 > requisite fields of the config files might be an answer that would
 > prevent some grief. Since they have to go in to change the username
 > anyway, it seems to me not to hurt the installation setup process any.
 > 

I have pondered this too, but I've seen problems everywhere. I'm not
sure whether package builders can handle this appropriately, since
RefDB is usually split at least into a server and a client package
which need to be configured differently. And besides, if users don't
care to configure their config files because they don't know they have
to, would they be likely to run a script that they don't know about?
That's why I attempted to put as much configuration as possible into
the most natural place for this - the configure script.

In any case, I welcome any suggestions to handle this better, as the
current approach apparently causes more problem than I'd like. Please
feel free to let the ideas flow.

regards,
Markus

-- 
Markus Hoenicka
[email protected]
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de



-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642