environment: SQLServer 6.5 .. OI 3.2 (tested OI 3.4 too)

I've got a (in my opinion) weird connection problem,

we have a customer that runs SQLServer over TCP/IP. This

machine is placed in a WinNT domain, and people who are logged into

the domain can access SQLServer from inside OI without any problems.

However, the customer also have some clients who are not allowed

to log into the WinNT domain, and .. these clients can't log into

SQLServer… BUT (!!) there's no problem connection from ISQL/W.

I did some experiments here trying to reproduce this error, and

I managed to do it .

Using old dlls, (SQLServer v4 distribution) I couldn't log in from

neither OI nor ISQL/W

I installed dlls (SQLServer v6 distribution), and with these I could

log into the database from ISQL/W (though it was an old 4.x version),

OI still couldn't log in though ……tried OI v3.2 and v3.4

and .. as expected .. when I logged into the domain, there were

no probs at all with OI either

something cms 2 go wrong when OI calls db_open() (??) ……

need quick help with this …

/bengt

Bengt,

I've got a (in my opinion) weird connection problem, we have a customer that runs SQLServer over TCP/IP. This machine is placed in a WinNT domain, and people who are logged into the domain can access SQLServer from inside OI without any problems. However, the customer also have some clients who are not allowed to log into the WinNT domain, and .. these clients can't log into SQLServer… BUT (!!) there's no problem connection from ISQL/W.

This applies to both SQL Server and Oracle. The database handles security by creating a thread for the connection; the thread "impersonates" the user by calling a function in the Windows API. If the user doesn't have a login ID, the request fails. I do not know how to either configure such behavior or turn it off.

Cameron Purdy

info@revelation.com

Bengt,

The connection code is "by the book". It uses a call to dbopen().

Cameron Purdy

info@revelation.com

is this really true ?? I don't have any problems logging into

an Oracle database when being outside a domain ?? don't think that

SQL*NET uses the OS's login procedures … if so .. how would it

be possible to access an Oracle database over the web ??

and .. question 2 .. why does ISQL/W work with the newer DLLs .. when

OI doesnt ???

/bengt

Bengt,

I don't have any problems logging into an Oracle database when being outside a domain ??

With our Oracle 7.3 Workgroup server on NT, I believe we had to establish user logins for the domain. Quite irritating. It is probably a security configuration option somewhere.

why does ISQL/W work with the newer DLLs .. when OI doesnt ???

I believe that ISQL/W is 32-bit, so it uses the 32-bit SQL Server DLL's. OpenInsight is a 16-bit application, so it uses the 16-bit DLL's. I have repeatedly noted Microsoft shipping working 32-bit DLL's and badly broken 16-bit DLL's; for example, SQL Server 6.5. I do not believe this to be purposeful; they simply do not test.

Assuming, however, that they both use the same DLL's and ISQL/W works, then I would guess one of the following:

1) ISQL/W uses a different combination of functions than OpenInsight

2) OpenInsight's connection object has a bug

As for the first, the following functions are used by the SQL Server connection object in OpenInsight:

W3DBLIB._dbcancel

W3DBLIB._dbcanquery

W3DBLIB._dbclose

W3DBLIB._dbcmd

W3DBLIB._dbcmdrow

W3DBLIB._dbcollen

W3DBLIB._dbcolname

W3DBLIB._dbcoltype

W3DBLIB._dbconvert

W3DBLIB._dbcount

W3DBLIB._dbdata

W3DBLIB._dbdatlen

W3DBLIB._dbdead

W3DBLIB._dberrhandle

W3DBLIB._dbexit

W3DBLIB._dbfreebuf

W3DBLIB._dbfreelogin

W3DBLIB._dbgettime

W3DBLIB._dbinit

W3DBLIB._dblogin

W3DBLIB._dbmsghandle

W3DBLIB._dbnextrow

W3DBLIB._dbnumcols

W3DBLIB._dbopen

W3DBLIB._dbresults

W3DBLIB._dbsetlname

W3DBLIB._dbsetlogintime

W3DBLIB._dbsettime

W3DBLIB._dbsqlexec

W3DBLIB._dbuse

W3DBLIB._dbvarylen

W3DBLIB._dbwinexit

Each is used according to the db-library specification provided by both Microsoft and Sybase. Theoretically, how could the processing work with one version of the DLL's but not another? For example, consider how you would try to break it for one version and not another … that would be pretty hard, wouldn't it? First you would have to find a function that DOES work in one version although you are using it incorrectly, and then you have to make sure it is broken (i.e. works as documented) in another version. Quite a task!

Cameron Purdy

info@revelation.com

ok Cam .. 4get about the MSSQL stuff .. if we reconfigured with

'trusted' connection we got response from the server .. so everything

is working fine .. (sorry 4 reporting an error that wasn't there)

the Oracle part sounds strange though … what I'm talking about

is connecting over SQL*NET v 2 over TCP/IP .. I mean, TCP/IP

shouldn't care at all about WIN NT and domains .. or should it ??

(don't know about the other protocols..) .. TNSLISTENER is plainly

listening to a port … and unless there are any firewalls or other

obstacles in the path there should be no problems to access the

Oracle server .. at least if the SQL*NET object is configured with

an IP addy .. otherwise you could get name resolution problems I guess ..

anyway .. enough about this .. guess you have other more important

problems to devote your attention to.. (especially considering that

this problem .. is no more ..)

y.s.

/Bengt

View this thread on the forum...