>
> Hello all,
>
> Sadly, I don't like how this question goes, but I'm at the
> end of my rope -- please bear with me :)
>
> I've created a simple script, which uses a DSN-less
> connection to grab some data from an MS SQL 2000 server and
> display it as XML. No big deal. I've installed Perl, DBI,
> DBD::ODBC and IIS on my local machine. The script runs fine and dandy.
>
> I've also copied the script to the test server; once again,
> it runs fine. Lastly, I copied it to the production server --
> and *BAM* all I get is a "CGI Timeout" when it tries to
> connect. (Note: all servers plus my machine have all of the
> needed modules at the same version. DBD::ODBC 0.28, btw)
0.28 had some problems with DSN-less connections if the connection
failed, but that usually caused an error that the connect didn't return
the right error information (i.e. DSN or string too long instead of
"server not responding"). That doesn't sound like the issue here,
but...upgrading to 0.43 might be a good idea. 1.02 is better, but
that's a switch to ODBC v3 specs where somethings are more strict.
YMMV.
>
> It should be noted that our network looks like this:
>
> +-----+ +----------+ +-----------------+
> | Web | --- | Firewall | --- | SQL (Port 1433) |
> +-----+ +----------+ +-----------------+
> |
> +--------+ |
> | My Box | -------------+
> +--------+ |
> |
> +----------+ |
> | Test Box | -------------+
> +----------+
>
> But, nothing is showing up in the firewall logs. The only IIS
> (version 5, btw) error is the "CGI Timeout." There's nothing
> in the MS SQL logs showing a connection from the specified
> user on the database in question. A simple test CGI .pl
> scripts runs fine (i.e. Perl works :). I've been able to
> connect to the MS SQL Server no problem with some test ASP scripting.
>
> Is there any way I can dig down deeper to see what exactly is
> happening when I call connect()? I tried to add a
> DBI->trace(), but it just times out. Any other ideas?
Can you put your test machine or your machine outside the firewall
temporarily to debug better? Turning on ODBC logging and/or DBI logging
should help determine with more detail, but it's probably SQLConnect not
returning.
I'd compare your connecting from ASP to your connect from Perl and see
what the difference is. It may be as complex as an IP routing issue on
the production machine, which *may* be why the firewall is not seeing
it. For example, depending upon your firewall, the IP you use on the
outside may be different than the inside... I'm assuming you've tested
that already, though, it's just one of the many possible things.
>
> Here's some of my code (X'ed out values have real values in the actual
> code):
>
> #!c:\perl\perl.exe -w
>
> use strict;
> use CGI;
> use DBI;
> use HTML::Template;
>
> my $database_name = 'LBC_research_test';
> my $database_user = 'NALD_admin';
> my $database_pass = 'XXXXXXXXXX';
>
> my $query = new CGI;
>
> my $id = $query->param('id') || send_err('No ID supplied');
>
> my $DSN = "driver={SQL
> Server};Server=XXX.XXX.XXX.XXX,1433;database=$database_name;ui
> d=$databas
> e_user;pwd=$database_pass;";
> my $dbh = DBI->connect("dbi:ODBC:$DSN") or die $DBI::errstr;
> # ^-- it never passes this line.
> my $sth = $dbh->prepare('EXEC usp_get_tag_data ?');
> $sth->execute($id) or die $DBI::errstr;
> my $ref = $sth->fetchall_arrayref({});
>
> # etc, etc.
>
> Thanks a million in advance!!
>
> -Brian
>
>
http://www.gordano.com - Messaging for educators.
