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

Status: RESOLVED FIXED

(Bugzilla :: Installation & Upgrading, defect, P2)

Description

[Stephen Rasku]

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. - [e-mail] 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.

Comment 1

[Dave Miller [:justdave]]

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.

Comment 2

[Dave Miller [:justdave]]

-> Installation/Upgrading

Comment 3

[Stephen Rasku]

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.

Comment 4

[Dave Miller [:justdave]]

how about DBD::mysql?  Maybe we're requiring too early a version of that...

Comment 5

[Stephen Rasku]

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

Comment 6

[Dave Miller [:justdave]]

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...

Comment 7

[Stephen Rasku]

If you don't specify the database name, what is the expected behaviour?  What is
it supposed to connect to?

Comment 8

[Dave Miller [:justdave]]

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.

Comment 9

[Dave Miller [:justdave]]

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

[Stephen Rasku]

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.

Comment 11

[Dave Miller [:justdave]]

ok, done.  If you run into it again or find any clues, reopen.

Comment 12

[Robin Smith]

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.

Comment 13

[Bradley Baetz (:bbaetz)]

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.

Comment 14

[Joel Peshkin]

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.

Comment 15

[Dave Miller [:justdave]]

has anyone seen this happen on a current Bugzilla version?  It's been a long
time since 2.14...

Comment 16

[Marc Schumann [:Wurblzap]]

Expecting that this has been FIXED in the meantime, optimistically marking
RESOLVED. Please reopen if I'm wrong.