Skip to Content.
Sympa Menu

freetds - Re: [freetds] DSQUERY as an IP vs a DSN

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT schemamania.org>
  • To: TDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] DSQUERY as an IP vs a DSN
  • Date: Wed, 18 Dec 2002 08:47:04 -0500

On Mon, 16 Dec 2002 21:41:51 -0700, "Andy Clark"
<andy AT abednegosystems.com> wrote:
>
> I appreciate your suggestions, and
> given what I can see on my end, I have no doubt they would all work.
> Unfortunately, the system needs to be a test copy of the production site
> and I need to recreate the production functionality exactly as it exists
> in the main system. I would happily implement the measures you
> recommend if I could, but modifying page code is not an option at this
> point. Having said that, here is the way I need to make this thing work
> (see dysfunctional snippet from previous posting below for sample code):
> - DBI->connect('dbi:Sybase:database=mydb', $usr, $pwd);
> - $DSQUERY specifies the data server IP
> - user, password, IP all specified in text "config" file to be
> parsed and assigned to page vars
>
> Can you point me in the direction of the "planets" that need to align?
> Based on the documentation, I would guess the planets are represented by
> ENV variables?

Andy,

I'm not perfectly sure I understand all you told me, but I'll try to point
you in the right direction.

By setting DSQUERY to the ip address, you're defeating FreeTDS's ability
to look up the server's characteristics in freetds.conf (or, in your case,
interfaces). The file might as well not be there.

In order for FreeTDS to connect successfully in such a case, "aligning the
planets" is a matter of making sure the runtime defaults match the
server's capabilities. As you surmise, you control FreeTDS's runtime
defaults through three mechanisms (mechanii?):

1. ./configure --with-tdsver=....
2. Environment variables.
3. freetds.conf [global] section.

That is, if you know what the server wants and set FreeTDS to meet them,
you'll connect.

(I assume you don't want to muck with freetds.conf, because it's not used
in your production system.)

You can test your connection with tsql -H host -p port ("man tsql" for
details). Specifying a host rather than a servername bypasses
freetds.conf. From what you tell me, this should work:

export TDSVER=7.0 # or 4.2
tsql -H 1.2.3.4 -p 1433 -U user -P pswd

(where "1.2.3.4" is the ip address , "user" the username and "pswd" the
password, of course).

I think setting the right combination of TDSVER and TDSPORT will reproduce
your production system's success, such as it is. I can't promise this
will always work, though, because connecting to the ip address on a wing
and a prayer is obviously an act of quiet desperation. Not to mention
very inflexible. But we won't go out of our way to break it, either.

We've seen that "connect to random addresses behavior" before. I don't
know what causes it, but it goes away when things are set up correctly, so
it's a minor problem from my point of view.

Hope that gets you cooking.

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page