checksetup.pl fails to connect when checking to see if database exists

RESOLVED FIXED in Bugzilla 2.20

Status

()

Bugzilla
Installation & Upgrading
P2
normal
RESOLVED FIXED
17 years ago
6 years ago

People

(Reporter: Stephen Rasku, Assigned: zach)

Tracking

2.14
Bugzilla 2.20
Sun
Solaris

Details

(Reporter)

Description

17 years ago
When upgrading from 2.12 to 2.14, I ran checksetup.pl.  The first time, I got a 
message about the create_htaccess variable in localconfig.  I changed this value
from 1 to 0 and re-ran checksetup.pl.  At this point I get the error:
--- 
Checking user setup ...
DBI->connect(;ottawa;3306) failed: No Database Selected at ./checksetup.pl line
736
Uncaught exception from user code:
        Can't connect to the mysql database. Is the database installed and
up and running?  Do you have the correct username and password selected in
localconfig?
---

The bugzilla database exists on ottawa.  There is a comment in the code about
the original dsn:

# original DSN line was:
#    my $dsn = "DBI:$db_base:$my_db_name;$my_db_host;$my_db_port";
# removed the $db_name because we don't know it exists yet, and this will fail
# if we request it here and it doesn't. - justdave@syndicomm.com 2000/09/16
 
I added $my_db_name in front of $my_db_host and the problem went away.  I
shouldn't have to edit this file.
what version of DBI do you have?  This sounds like you have an old version of
DBI, though checksetup.pl should be checking for that as well.  If you notice
the date on that comment, that code has been there since before 2.12, so you
should have had this same problem upgrading to 2.12 if it were Bugzilla's fault.
-> Installation/Upgrading
Assignee: justdave → zach
Component: Administration → Installation
(Reporter)

Comment 3

17 years ago
Checking for             DBI (v1.13)   ok: found v1.14

I believe that I did have this problem upgrading to 2.12 as well.  I just didn't
report a bug at that time.
how about DBD::mysql?  Maybe we're requiring too early a version of that...
(Reporter)

Comment 5

17 years ago
Checking for      DBD::mysql (v1.2209) ok: found v2.0415
This machine works: (PPC G3, Darwin 1.3.7 / Mac OS X 10.0.4)

Checking for             DBI (v1.13)   ok: found v1.16
Checking for      DBD::mysql (v1.2209) ok: found v2.0901

This one works: (i386, RedHat 7.1)

Checking for             DBI (v1.13)   ok: found v1.15
Checking for      DBD::mysql (v1.2209) ok: found v2.0415

OK, that rules out DBD::mysql, since you have the same version I do.

This one works:  (i386, RedHat 6.2)

Checking for             DBI (v1.13)   ok: found v1.14
Checking for      DBD::mysql (v1.2209) ok: found v2.0415

OK, that one is the same version on both counts.

Something is screwy somewhere with your install I think...
(Reporter)

Comment 7

17 years ago
If you don't specify the database name, what is the expected behaviour?  What is
it supposed to connect to?
The expected behavior is that you connect to the database server without
connecting to a specific database.  This is necessary on the first run on
checksetup.pl because it has no clue whether the bugs database exists yet or
not, and if we try to connect to it and it doesn't, it bombs horribly (which was
the behavior in 2.10).  So you connect without specifying a database, then ask
it what databases you have access to.  If the one in $db_name isn't in the list,
then we create it.
Stephen, any progress with this?  I haven't seen any error reports from anyone
else, and I can verify it works as expected everyplace I have access to.  I'm
tempted to mark WORKSFORME, but I want to make sure you haven't made any
interesting discoveries first.

Comment 10

17 years ago
No, I haven't had time to look at this.  You can mark it WFM if you want and if
I get around to it before 2.16 is released I will re-open it.
ok, done.  If you run into it again or find any clues, reopen.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 12

16 years ago
I also am encountering this problem, here is the output from checksetup.pl :

Checking perl modules ...
Checking for             DBI (v1.13)   ok: found v1.13
Checking for    Data::Dumper (any)     ok: found v2.09
Checking for      DBD::mysql (v1.2209) ok: found v2.0217
Checking for     Date::Parse (any)     ok: found v2.09
Checking for       CGI::Carp (any)     ok: found v1.13

The following Perl modules are optional:
Checking for              GD (v1.19)    found v1.18
Checking for     Chart::Base (v0.99)    not found
Checking for     XML::Parser (any)     ok: found v2.27

If you you want to see graphical bug dependency charts, you may install
the optional libgd and the Perl modules GD-1.19 and Chart::Base-0.99b, e.g. by
running (as root)

   perl -MCPAN -e'install "LDS/GD-1.19.tar.gz"'
   perl -MCPAN -e'install "N/NI/NINJAZ/Chart-0.99b.tar.gz"'

Checking user setup ...
DBI->connect failed:  at checksetup.pl line 761
Uncaught exception from user code:
        Can't connect to the mysql database. Is the database installed and
up and running?  Do you have the correct username and password selected in
localconfig?

Adding the db name to the connect statement allows checksetup.pl to continue.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
We should probably use the DBI routines to get name sof databases. Don't know if
mysql's dbd stuff support that, although I think it does.
Priority: -- → P2
Target Milestone: --- → Bugzilla 2.18

Comment 14

14 years ago
Unloved bugs targetted for 2.18 but untouched since 9-15-2003 are being
retargeted to 2.20
If you plan to act on one immediately, go ahead and pull it back to 2.18.
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
has anyone seen this happen on a current Bugzilla version?  It's been a long
time since 2.14...
Summary: Upgrade from 2.12 to 2.14 fails → checksetup.pl fails to connect when checking to see if database exists
Expecting that this has been FIXED in the meantime, optimistically marking
RESOLVED. Please reopen if I'm wrong.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago13 years ago
Resolution: --- → FIXED
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.