Skip to Content.
Sympa Menu

freetds - RE: RE: [freetds] ASA Error -83: Specified database not found

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT ais.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: RE: RE: [freetds] ASA Error -83: Specified database not found
  • Date: Thu, 27 Feb 2003 18:08:24 -0500 (EST)

On Thu, 27 Feb 2003, Lowden, James K wrote:

> > From: Brian Bruns [mailto:camber AT ais.org]
> > Sent: February 27, 2003 4:20 PM
> >
> > this is not a
> > problem when using ASA 5.5 with OSG, just with native support
> > under 6.0 (and higher I presume).
>
> The older product works correctly? Only ASA 6.0+ insists we pass the
> database name in the lservname login packet? Thanks for looking into this.

5.5 with OSG is a different beast entirely, but Watcom (come ASA) didn't
really support things like select t1.col1, t2.col2 from db1..t1, t2
for instance. So, there is no tempdb, no sense of a server with several
databases to speak of....again this may have changed.
>
> > The problem is that the database *is* the server
> > name under ASA. That is, if you have two databases you have
> > two services under Win32.
>
> Same port? Does "select @@servername = db_name()" always returns 1?

Ok, let me take that back...the server has its own name too...but under
OSG, servername sent with login is lost at the gateway...I'd like to see
"select @@servername, db_name()" from Marco to be sure what is going on.

> > I'd reccommend having a servername = blah entry in the
> > freetds.conf that
> > defaults to the [] name and is sent with the login
> > packet...no need for
> > special ASA logic, it can be used globally. Sending the alias name
> > isn't always the best strategy. I'll try to wrap up a patch
> > like this if it sounds good. 0.62 fodder...
>
> I don't like that idea very much; I think it's too open-ended. It's hard
> enough to get folks to understand the ip->hostname->servername relationship
> (particularly given the odd use of "hostname" -- i.e. client workstation's
> claimed name -- in the vendor docs). The smart folks would ignore a
> "servername" line; the lucky ones would set it to the [] name; and the rest
> would write to the list wondering what to do. Of course, some people would
> spend time in more than one category....


Good points. The curse of configurability.

> I think it would be better to have an optional "server type" entry. The
> domain would be Vendor-[Model-]version:
>
> Microsoft-[6.5 | 7.0 | 2000]
> Sybase-[10 | 11 | 12.5]
> Sybase-ASA-[5.5 | 6.0 | ...]
>
> This lets us do server-specific processing and/or consistency checking:
>
> A. Trivially, for example, we could verify that the stated server type
> supports the requested TDS version before attempting to connect.
>
> B. In this case, we could swap in the dbname, if provided, for the
> servername in lsrvname if the servertype is in out ASA list.
>
> C. If there's a servertype and no tds version specified, we could make a
> reasonable choice based on the server type instead of falling back on
> --with-tds-version.
>
> Granted, "server type" places the onus on us. It's no more work to parse
> out of the file, but it forces us to decide what to do based on the value.
> OTOH, it moves from prescription to description, which on the whole is
> easier to support and use.
>
> Could you get behind that?

As a sort of "meta option" I think it's a good step at reducing the mess.
Each metatype would flip a lot of other bits which could be overriden by
explicitly declaring them.

Two other thoughts, we still need a testparm program ala Samba to test the
syntactic (hostname = foo, should be host = foo) and semantic (tds 7.0
against Sybase, or try domain with tds 4.2) problems.

Lastly, better login time error reporting. Specifically, detecting domain
only servers and printing out detailed instructions for correcting "Please
set 'try domain login = true' in freetds.conf". Or when connect fails,
say something about were we able to reach the server? Check host,
port. Were we closed after sending the packet? check TDS version.
etc....Embedding some of the troubleshooting steps into the code and
providing instant feedback without having to consult documentation I guess
is what I'm saying. Only in fatal cases of course.

> (Also, I was hoping to hear from you re AIX and rc5.)

Will do tommorow morning (Friday, EST) been busy (as usual). Will report
in the afternoon on success/fail. Only have sybase there to test though.

> Best regards old man,
>
> --jkl
>

Cheers,

Brian






Archive powered by MHonArc 2.6.24.

Top of Page