Inline Mysql not able to connect (?)

TS 6.1.0 SP1, Win2k3

I have two scripts that are basically identical -- one is a Mysql callout and the other is an inline command, both called from the same DCT for now.

The callout works just fine, but the inline version does not. It returns the following error:

Root cause:
Mysql connect('database=<DB>;host=<HOST>:3306','<USER>',...) failed: Can't create TCP/IP socket (10106) at <SCRIPT> line 9 Can't call method "selectdb" on an undefined value at <SCRIPT> line 10.

Here is the script:

use Mysql;

$password = "<PASSWORD>";
$host = "<HOST>:3306";
$database = "<DB>";
$user = "<USER>";
$dbh = Mysql->connect($host,$database,$user,$password);
$dbh->selectdb($database);

$sth = $dbh->query("<QUERY>");
print qq^<substitution>^;
while (my $ref = $sth->fetchrow_arrayref) {
print qq^<option label="$$ref[0]" value="$$ref[0]"/>^;
}
print qq^</substitution>^;

exit();

(Important to note also that I've attempted this with and without the port number.)

Does anyone see some obvious flaw that I overlooked?? Please advise,

Dave

Find more posts tagged with

Comments

Dwayne

I don't know if this is related or not, but I know that when using the ODBC driver you need to set the SYSTEMROOT environment variable in order for the connection to succeed. Perhaps there's something similar going on here, where the code can't create the socket because there's an environment variable that Windows needs in order to find a library or something.

You might try capturing the ENV array from the callout version, and then explicity setting the same values in your inline version, to see if it helps. If it does, you can do a "binary search" on the variables, to see which one is causing the problem.

If not, then I'm not sure what's wrong. I didn't see anything obvious in the code.

--

Current project: TS 5.5.2/6.1 W2K

Migrateduser

Interesting... that would make sense and my initial thought was that it was some environmental thing that's affecting the inline version and not the callout version.

I will try that and repost when I have more information to share :-)

Thanks, Dwayne.

Adam Stoller

Put the following code in your scripts and run them - and then look at the differences:use File::Temp qw(tempfile);
my($fh, $tmpf) = tempfile();
print $fh "$_ = $ENV{$_}\n" foreach(sort(keys(%ENV)));
close($fh);
print STDERR "LOOK AT FILE: $tempf\n";Hopefully the last line will go to one or more of the logs (e.g. iwtrace.log or iwui/error_log or something like that).

My guess is that you'll find certain environment variables related to the DB and/or LIB paths that differ between the two uses of the script - you'll need to replicate this information within a BEGIN{...}; block in order for your code to work when the information isn't already in the %ENV hash.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Edited by ghoti on 09/08/04 05:38 AM (server time).

Migrateduser

I plugged in all the environment variables that the other one had and I'm stuck with the same connection problem.

I suppose the (very) least common denominator is that I could fork a shell from the Perl script and that might do it -- but that would suck, basically.

What else might it be?

Dave

Adam Stoller

*How* did you "plug in all the environment variables" ?

Can you post the script in which you did this?

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

Basically, I just issued Perl statements equivalent to the following:

set PATH=C:\WINDOWS\system32\...., etc.

Does that not seem right or should I instead write Java-type statements because it's an inline?

Dave

Adam Stoller

Dave - your original post clearly indicated that your inline script was written in Perl - as such you need to use Perl code to set the environment information. The code you want would look something like this:BEGIN{
$ENV{env_variable_name1} = "env_variable_value1";
$ENV{env_variable_name2} = "env_variable_value2";
...
};I don't believe you would need to set PATH, but you might need to set something like LD_LIBRARY_PATH and/or some other variables that are explicitly for the DB.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

I actually tried that first (with the BEGIN statement, etc.) but did not see any LD_LIBRARY_PATH provided by the other environment variable dump and continued to receive the error message from above.

Here are the variables I am getting in the env var dump:



$ENV{'COMSPEC'}
$ENV{'CONTENT_LENGTH'} 
$ENV{'CONTENT_TYPE'} 
$ENV{'DOCUMENT_ROOT'} 
$ENV{'GATEWAY_INTERFACE'} 
$ENV{'HTTP_ACCEPT'} 
$ENV{'HTTP_ACCEPT_ENCODING'} 
$ENV{'HTTP_ACCEPT_LANGUAGE'} 
$ENV{'HTTP_CACHE_CONTROL'} 
$ENV{'HTTP_CONNECTION'} 
$ENV{'HTTP_COOKIE'} 
$ENV{'HTTP_HOST'} 
$ENV{'HTTP_REFERER'} 
$ENV{'HTTP_USER_AGENT'} 
$ENV{'IWUSER'} 
$ENV{'PATH'} 
$ENV{'QUERY_STRING'} 
$ENV{'REMOTE_ADDR'} 
$ENV{'REMOTE_PORT'} 
$ENV{'REQUEST_METHOD'} 
$ENV{'REQUEST_URI'} 
$ENV{'SCRIPT_FILENAME'} 
$ENV{'SCRIPT_NAME'} 
$ENV{'SCRIPT_URI'} 
$ENV{'SCRIPT_URL'} 
$ENV{'SERVER_ADDR'} 
$ENV{'SERVER_ADMIN'}
$ENV{'SERVER_NAME'} 
$ENV{'SERVER_PORT'} 
$ENV{'SERVER_PROTOCOL'} 
$ENV{'SERVER_SIGNATURE'} 
$ENV{'SERVER_SOFTWARE'} 
$ENV{'SYSTEMROOT'} 
$ENV{'WINDIR'}

What do you think?

Dave

Adam Stoller

Hmm - I don't see anything there that stands out as being DB-specific - maybe someone else can spot something or figure out something we missed looking at. Sorry.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

It's interesting though that there were so many additional environment variables present in the callout than in the inline, where there only 4, initially.

So, I've tried to specify the port, set the environment variables, etc., but perhaps there's something else inherently about the inline environment that's not allowing it to proceed?

Dave

Adam Stoller

The inline's environment is intentionally blanked out and only Interwoven-specific environments are set.

But without knowing what specific environment variables you are relying on, there's no easy way to figure out what to set -- and of course it could be something completely different ...

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

That's the problem, I think -- I didn't know I was relying on any environment variables, just scripting and a Perl module or two.

I've actually done some reading on others having very similar problems as this. It seems as though it's not uncommon, but so far, after reading posts that date back to 2002, no one has come up with an answer to this. It may be a Tomcat issue, but then again it may also be a Windows issue. Basically, I think the blame is off of Interwoven but without trying to change the world, I wonder how I can hack a way around this problem.

Dave

Adam Stoller

Take a look at this webpage and see if you can make use of it (you can ignore the first four variables shown).

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

*sigh* unfortunately, no. I should mention that the Mysql database is on a different server than TS is on. It's giving me a TCP/IP socket-related error (or, at least it appears to be). I wonder if Tomcat's to blame here.

Dave

Adam Stoller

I'm not sure why tomcat would be involved - but I think I've exhausted the amount of assistance I can provide.

Good luck - let us all know if you figure out how to fix it.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

Absolutely will -- thanks for the clues you've given so far!

Dave

Migrateduser

I thought I would post a follow-up to this --

In the interest of time, etc., I didn't wind up fixing this at all, but managed a certainly viable workaround. I have a copy of the database on the TS box which receives updates from the actual DB server nightly. No, it's not perfect but it is certainly suitable, as certain fields are not going to be changing all that often anyway.

So, I was also unable to use the inline query... unfortunately, what I've had to do for that is simply force a callout. This is the worst sticking point for me. I'd greatly prefer the inline query, but for whatever reason (may likely be Windows-related; I don't think it's a TeamSite thing), the port cannot communicate when the query is executed from that interface.

This is much less than stellar, but I wanted to psot a follow-up to this.

Dave

---
Interwoven Humor Page
http://iw.simpleinternet.com

Migrateduser

> "dave" wrote:
>
> Interwoven Humor Page
> http://iw.simpleinternet.com

http://iw.simpleinternet.com/images/private/custompt.jpg

This one's not so funny - is there yet a resource on "How to Write a Custom Presentation Template Tag"? Is this resource only on support.interwoven.com (I don't have access), or is it on my TeamSite server, an open site or devnet?

Is anyone using custom presentation template tags? What are the issues?

Regarding http://iw.simpleinternet.com/images/private/iwwftodo.jpg, one day there were so many of these on the system that they made a wallpaper. The problem seemed to happen if a user changed their NT domain password without logging out of TeamSite, not sure if that's been corrected.

Thanks,

-John

Migrateduser

Thanks again for these, John :-)

I actually found equally embarrasing things coming from the buy.com web site this morning -- DB connection and other errors on the HOME PAGE. Anyway, I took screen shots... maybe there IS a desire for this stuff??

Dave

---
Interwoven Humor Page
http://iw.simpleinternet.com