fails to create database with password

RESOLVED FIXED in Bugzilla 2.12



18 years ago
6 years ago


(Reporter: justdave, Assigned: justdave)


Bugzilla 2.12


(Whiteboard: 2.12)


(2 attachments)

As pointed out in bug 16454, the patch that was checked in as a result of that 
bug allowed you to update an existing bugzilla configuration if the database was 
password-protected.  However, it still did not allow you to *create* a database 
on such a system for the initial setup.  That bug was marked fixed, and a comment 
said a new bug report should be opened for the problem with creating a database.  
I haven't seen one yet, so this is it.

I have a new patch I'll be posting shortly that fixes this. :)

The trick was just to remove the database name from the connect string.  It was 
trying to log into the database server and select that database in one fell 
swoop, but that was a bad thing because we didn't know the database exists yet at 
that point.  Now it logs into the server but doesn't select a database (which is 
good because we're logging in at this point in order to see what databases are 
there - we don't even know what's there yet).

While I was messing with it, I also discovered that got missed when 
we did the 5.6 compatibility update on, so that is also included in 
this patch.
Created attachment 14855 [details] [diff] [review]
patch to allow to create a password-protected database, also resolves some Perl 5.6 compatibility issues
I'll leave this for a few days to give other people a chance to look at it and 
make sure I didn't do anything stupid before I check it in.
Keywords: patch
Whiteboard: 2.12

Comment 3

18 years ago
The patch looks good to me.
ok, it's checked in.
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 5

18 years ago
if ($::db_check) {
    # Do we have the database itself?
# original DSN line was:
#    my $dsn = "DBI:$db_base:$::db_name;$::db_host;$::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. - 2000/09/16
    my $dsn = "DBI:$db_base:;$::db_host;$::db_port";

I had to undo this change in my installation because not supplying a db name
caused an error.

my version is 10.14 which is not an unlikely version for current 
bugzilla sites to be using. If we need a newer version then can we get to check for that?

# $Id:,v 10.14 1999/05/13 01:44:25 timbo Exp $

Resolution: FIXED → ---
OK, here's the version I'm running on one of my servers where that works:

# $Id:,v 10.32 2000/06/14 20:04:03 timbo Exp $

The system I was using when I wrote that patch has this one:

# $Id:,v 10.25 1999/07/12 02:02:33 timbo Exp $

Anyone know which version of DBI that change was made in?
Hmm, not sure what the significance of the numbers in those version lines in the 
actual file is...  investigated a way for to test this, and 
the that has the 10.25 line reports $DBI::VERSION as 1.13, the 10.32 
reports it as 1.14.   1.13 sounds familiar...  I could swear that something I 
installed in the process of setting up Bugzilla (the DBI::mysql module?) said it 
required 1.13....

Shall we make Bugzilla require version 1.13 or newer of DBI?
Created attachment 22552 [details] [diff] [review] checks for version 1.13 or later of DBI
The original issue on this bug has been fixed.  The reason it was reopened turned 
out to be a too-old version of DBI.  This has been filed as a new bug in Bug 
65598.  Making this one FIXED again, and the new problem will be dealt with over 
in 65598.
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 10

18 years ago
Sorry for the spam, but I needed to be able to query for all of these correctly.
Target Milestone: --- → Bugzilla 2.12
Moving closed bugs to Bugzilla product
Component: Bugzilla → Bugzilla-General
Product: Webtools → Bugzilla
Version: other → unspecified
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.