It's not ODBC - It's not ASP - It's OLE/DB

It's not ODBC - It's not ASP - It's OLE/DB

Post by JB » Wed, 11 Oct 2000 04:00:00



[OLE/DB provider returned message: Client unable to establish connection]
[DBNMPNTW]ConnectionOpen (CreateFile()).

This error is supposedly a Security issue.  If so, it an un-resolvable
security issue.

According to "Security for Linked Servers" in BOL and sp_addlinkedsrvlogin I
should not be getting this error.  Can anyone please tell me in an
un-encrypted way, how to make a distributed transaction work from Windows
2000 to Windows NT?  I cannot come up with a combination that works - I have
been at it for two days.

 
 
 

It's not ODBC - It's not ASP - It's OLE/DB

Post by Richard Waymir » Wed, 11 Oct 2000 04:00:00


This looks like the NT account you're using doesn't have rights on the
remote computer.  For some reason it's trying to use named pipes.  You might
try switching the default network library on your server (via the client
network utility) to tcp/ip sockets and see if it's an NT permissions issue.

--
Richard Waymire, MCDBA, MCSE, MCSD


Quote:> [OLE/DB provider returned message: Client unable to establish connection]
> [DBNMPNTW]ConnectionOpen (CreateFile()).

> This error is supposedly a Security issue.  If so, it an un-resolvable
> security issue.

> According to "Security for Linked Servers" in BOL and sp_addlinkedsrvlogin
I
> should not be getting this error.  Can anyone please tell me in an
> un-encrypted way, how to make a distributed transaction work from Windows
> 2000 to Windows NT?  I cannot come up with a combination that works - I
have
> been at it for two days.


 
 
 

It's not ODBC - It's not ASP - It's OLE/DB

Post by JB » Wed, 11 Oct 2000 04:00:00


Thanks for responding, Richard.  I switched everything to TCP/IP.  My 98
machine was already on TCP/IP.  Named Pipes is the installation default on
both NT and Windows 2000.  It is now set to TCP/IP though.  My client's
application has to work on NT 4.0, Windows 2000 and Windows 98 without any
complications.  So far, ...  I have lost all confidence in Microsoft.   A
security system that is so secure that the owners can't use it is not
exactly what they should have produced in my opinion - apparently, this is a
security issue.

I would pay big bucks for a variation of VB that works under Linux.  Sql
Server 7 has some really great features - too bad the one I need the most,
Distributed Transactions, doesn't work in a logical, predictable way.  It
worked, as I said, before I re-installed my dev computer, but not since.
I'm really frustrated by the CRAP!!!!  Now I've lost another WHOLE day.


> This looks like the NT account you're using doesn't have rights on the
> remote computer.  For some reason it's trying to use named pipes.  You
might
> try switching the default network library on your server (via the client
> network utility) to tcp/ip sockets and see if it's an NT permissions
issue.

> --
> Richard Waymire, MCDBA, MCSE, MCSD



> > [OLE/DB provider returned message: Client unable to establish
connection]
> > [DBNMPNTW]ConnectionOpen (CreateFile()).

> > This error is supposedly a Security issue.  If so, it an un-resolvable
> > security issue.

> > According to "Security for Linked Servers" in BOL and

sp_addlinkedsrvlogin

- Show quoted text -

Quote:> I
> > should not be getting this error.  Can anyone please tell me in an
> > un-encrypted way, how to make a distributed transaction work from
Windows
> > 2000 to Windows NT?  I cannot come up with a combination that works - I
> have
> > been at it for two days.

 
 
 

It's not ODBC - It's not ASP - It's OLE/DB

Post by Richard Waymir » Wed, 11 Oct 2000 04:00:00


I'm not sure I understand the complaint... If all the machines are part of
the same domain structure, then everything just works.  The reason this is
failing with named pipes is that named pipes is a secure connection
mechanism in the sense that you have to have rights to the NT box for you to
be able to connect to it - if this wasn't the case, you'd get complaints
that just anyone can connect to the NT box.  Security is always a
double-edged sword.  I'm frankly not sure it'd be any better on another
platform - everyone in the industry is struggling with making the machines
more secure.

As to the sockets issue, tcp/ip is the default for all platforms with SQL
Server 2000.

--
Richard Waymire, MCDBA, MCSE, MCSD


> Thanks for responding, Richard.  I switched everything to TCP/IP.  My 98
> machine was already on TCP/IP.  Named Pipes is the installation default on
> both NT and Windows 2000.  It is now set to TCP/IP though.  My client's
> application has to work on NT 4.0, Windows 2000 and Windows 98 without any
> complications.  So far, ...  I have lost all confidence in Microsoft.   A
> security system that is so secure that the owners can't use it is not
> exactly what they should have produced in my opinion - apparently, this is
a
> security issue.

> I would pay big bucks for a variation of VB that works under Linux.  Sql
> Server 7 has some really great features - too bad the one I need the most,
> Distributed Transactions, doesn't work in a logical, predictable way.  It
> worked, as I said, before I re-installed my dev computer, but not since.
> I'm really frustrated by the CRAP!!!!  Now I've lost another WHOLE day.



> > This looks like the NT account you're using doesn't have rights on the
> > remote computer.  For some reason it's trying to use named pipes.  You
> might
> > try switching the default network library on your server (via the client
> > network utility) to tcp/ip sockets and see if it's an NT permissions
> issue.

> > --
> > Richard Waymire, MCDBA, MCSE, MCSD



> > > [OLE/DB provider returned message: Client unable to establish
> connection]
> > > [DBNMPNTW]ConnectionOpen (CreateFile()).

> > > This error is supposedly a Security issue.  If so, it an un-resolvable
> > > security issue.

> > > According to "Security for Linked Servers" in BOL and
> sp_addlinkedsrvlogin
> > I
> > > should not be getting this error.  Can anyone please tell me in an
> > > un-encrypted way, how to make a distributed transaction work from
> Windows
> > > 2000 to Windows NT?  I cannot come up with a combination that works -
I
> > have
> > > been at it for two days.

 
 
 

It's not ODBC - It's not ASP - It's OLE/DB

Post by JB » Thu, 12 Oct 2000 04:00:00


I was not asking for your understanding of "the complaint".  You have nearly
nothing of the whole picture we are experiencing here.  I am simply voicing
my frustrations so as to have an outlet for the pressure.  This should be
carried no further.  Thanks again for responding to my plight.


> I'm not sure I understand the complaint... If all the machines are part of
> the same domain structure, then everything just works.  The reason this is
> failing with named pipes is that named pipes is a secure connection
> mechanism in the sense that you have to have rights to the NT box for you
to
> be able to connect to it - if this wasn't the case, you'd get complaints
> that just anyone can connect to the NT box.  Security is always a
> double-edged sword.  I'm frankly not sure it'd be any better on another
> platform - everyone in the industry is struggling with making the machines
> more secure.

> As to the sockets issue, tcp/ip is the default for all platforms with SQL
> Server 2000.

> --
> Richard Waymire, MCDBA, MCSE, MCSD



> > Thanks for responding, Richard.  I switched everything to TCP/IP.  My 98
> > machine was already on TCP/IP.  Named Pipes is the installation default
on
> > both NT and Windows 2000.  It is now set to TCP/IP though.  My client's
> > application has to work on NT 4.0, Windows 2000 and Windows 98 without
any
> > complications.  So far, ...  I have lost all confidence in Microsoft.
A
> > security system that is so secure that the owners can't use it is not
> > exactly what they should have produced in my opinion - apparently, this
is
> a
> > security issue.

> > I would pay big bucks for a variation of VB that works under Linux.  Sql
> > Server 7 has some really great features - too bad the one I need the
most,
> > Distributed Transactions, doesn't work in a logical, predictable way.
It
> > worked, as I said, before I re-installed my dev computer, but not since.
> > I'm really frustrated by the CRAP!!!!  Now I've lost another WHOLE day.



> > > This looks like the NT account you're using doesn't have rights on the
> > > remote computer.  For some reason it's trying to use named pipes.  You
> > might
> > > try switching the default network library on your server (via the
client
> > > network utility) to tcp/ip sockets and see if it's an NT permissions
> > issue.

> > > --
> > > Richard Waymire, MCDBA, MCSE, MCSD



> > > > [OLE/DB provider returned message: Client unable to establish
> > connection]
> > > > [DBNMPNTW]ConnectionOpen (CreateFile()).

> > > > This error is supposedly a Security issue.  If so, it an
un-resolvable
> > > > security issue.

> > > > According to "Security for Linked Servers" in BOL and
> > sp_addlinkedsrvlogin
> > > I
> > > > should not be getting this error.  Can anyone please tell me in an
> > > > un-encrypted way, how to make a distributed transaction work from
> > Windows
> > > > 2000 to Windows NT?  I cannot come up with a combination that
works -
> I
> > > have
> > > > been at it for two days.

 
 
 

1. VC5.0's ODBC is not compatible with VC4.2's ODBC

Hi Folks
We have an application developped under Visual C++ 4.2 using
ODBC text driver. We distribute related ODBC dlls and our exe files to
our customers. Recently we found that some software including
visual C++ 5 overwrite those ODBC dlls that we distributed and
our application does not work any more. Right now we have no
intention to upgrade our application to Visual C++ 5.
What can we do in this situation?

Thank you very much.

Ben

2. Can the Oracle db_block_size be changed on an instance?

3. ASP will not complete SQL's DTS packages that call to remote Access DB

4. 457: SQL engine terminated unexpectedly - please help

5. ASP, ADO, Access DB = err 80040E09 'Can't update DB. Read Only

6. Returning a recordcount from Stored procedure

7. [SQL] Re: why the DB file size does not reduce when 'delete'the data

8. OdbcTcl and D3?

9. ODBC 'feature not implemented' driver problem

10. OLE DB provider 'SQLOLEDB' does not contain table 'mytable'

11. OLE DB Provider for SQL return '.8' not '0.8'

12. like '%' not return null's

13. Microsoft's OLE DB Simple Provider 1.5 Library isn't cutting it :(