Skip to Content.
Sympa Menu

freetds - RE: make test fails

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: John Dejournett <johnde AT greeley.sykes.com>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: RE: make test fails
  • Date: Fri, 17 Mar 2000 16:54:34 -0700


Brian,

Sorry, I was typing without thinking. According to the local SA, the server
uses server logins.

Sincerely,
John DeJournett
HP ScanJet Developer Support
HP_SCAN AT greeley.sykes.com
Fax: (970) 346-2254



-----Original Message-----
From: Brian Bruns [mailto:camber AT umcc.ais.org]
Sent: Friday, March 17, 2000 4:55 PM
To: TDS Development Group
Subject: [freetds] RE: make test fails



On Fri, 17 Mar 2000, John Dejournett wrote:

> Brian,
>
> Sorry it took a while to respond, but I wanted to make
sure that I had
> accurate information. I have confirmed that the server is
using domain
> logins.
>
Ok, there's the problem then. SQL Server must be configured
with 'server
logins'. Domain logins don't work, as the linux box is not
a member of the
domain among other technical reasons that I don't even
altogether fathom
(domains work on DCE/RPC over SMB, so some sort of
integration with the
samba client would most likely be required to make it work).

So, two options, turn on server logins or use an ODBC-ODBC
bridge product
(which requires software on both linux and NT sides).

Of course, I'd happily accept patches for making domain
logins work :-) (or
even network traces of a domain login would be great!)

Brian
> Generally the server is accessed from windows platforms
via ODBC. The setup
> process we use is as follows
>
> 1. install the MS-SQL client configuration utility.
> 2. Install 32-bit ODBC (latest revision)
> 3. Configure ODBC as follows:
> * Data source name: SIMS
> * Description: Blank
> * Server: Server's IP address
> * Network Address Server's IP address, Port
> * Network Library DBMSSOCN
> 4. Configure the SQL Client Configuration utility as
follows:
> * Server: Server's IP address
> * DLL Name: DBMSSOCN
> * Connect String: Server's IP address, Port
> 5. Install one of the various DB front end packages we
use in-house.
> 6. Configure front end to access DB server by the ODBC
Data Source
> Name.
>
> The machines that connect to the DB server may be on one
of several domains,
> and the logins used in accessing the DB server are of a
different form from
> the domain logins.
>
> Sincerely,
> John DeJournett
>
>
>
> -----Original Message-----
> From: Brian Bruns
[mailto:camber AT umcc.ais.org]
> Sent: Wednesday, March 15, 2000 7:58 PM
> To: TDS Development Group
> Subject: [freetds] RE: make test
fails
>
> John,
>
> Hmmm...are you absolutely sure the server is
not using
> domain logins? You
> said you were able to login from a different
client, can you
> provide some
> details on that (I'm assuming it is a Win
box, is it part of
> the NT
> domain...etc...)
>
> I can't imagine we are that far away from
getting this...at
> worst I can
> provide you with a trace server to capture
the traffic and
> compare against
> what you see in the freetds.log
>
> Brian
>
> On Wed, 15 Mar 2000, John Dejournett wrote:
>
> > Brian,
> >
> > The platform is Slackware Linux (Intel).
I know that the
> server is running
> > at least NT4.0 SP5, but I don't think I
would bet on it
> being any more
> > current than that. The MSSQL is version
6.5.
> >
> > I just build SQSH, and it did build
correctly against the
> libraries (with a
> > little help from the FAQ page), but I
don't know that I am
> using it
> > correctly. The command line that I am
using is: sqsh -D
> DBName -S
> > ServerName (from the interfaces file) -U
UserName
> >
> > SQSH responds with the standard banner and
a password
> prompt. I enter my
> > password, and the program shuts down
without reporting any
> error or
> > otherwise status information. Am I going
about this
> incorrectly for
> > interactive mode? SQSH may be seeing the
same problem as
> the test programs,
> > but without further confirmation I would
hesitate to make
> that assumption.
> >
> > I don't particularly want to give up on
FreeTDS for this
> project (time not
> > being an issue), but that this point I am
starting to
> wonder if I shouldn't
> > backtrack and look at using an ODBC for
the database
> connectivity. Am I
> > just beating a dead horse here, or do you
think that this
> is something that
> > is potentially resolvable if we keep
working at it?
> >
> > Sincerely,
> > John DeJournett
> >
> >
> >
> > -----Original Message-----
> > From: Brian Bruns
> [mailto:camber AT umcc.ais.org]
> > Sent: Tuesday, March 14,
2000 6:45 PM
> > To: TDS Development
Group
> > Subject: [freetds]
Re: make test
> fails
> >
> > Ok, looks exactly like a bad
> username/password pair...Out of
> > curiousity
> > which platform is this on
(Linux Intel?).
> Also what service
> > pack are you
> > running on the server side?
And...have
> attempted to compile
> > SQSH to see
> > if that works?
> >
> > This is certainly a good
one.
> >
> > Brian
> >
> > On Mon, 13 Mar 2000, John
Dejournett wrote:
> >
> > > Brian,
> > >
> > > I am attaching my FreeTDS
log file. I
> have edited it a
> > little for obvious
> > > security reasons. I may
have the user
> name and password
> > transposed since
> > > they are the same for this
particular
> account, but this
> > should reasonably
> > > accurate.
> > >
> > > Sincerely,
> > > John DeJournett
> > >
> > > <<tdslog.txt>>
> > >
> >
>
>
> ---
> You are currently subscribed to freetds as:
> johnde AT greeley.sykes.com
> To unsubscribe, forward this message to
> $subst('Email.Unsub')
>
> ---
> You are currently subscribed to freetds as: camber AT ais.org
> To unsubscribe, forward this message to
$subst('Email.Unsub')
>
>


---
You are currently subscribed to freetds as:
johnde AT greeley.sykes.com
To unsubscribe, forward this message to
$subst('Email.Unsub')




Archive powered by MHonArc 2.6.24.

Top of Page