SQLError 401 Cannot open database with ODBC

[Patrick Geiser]

Hi,

I read so many articles about problems with ODBC, but still cannot find
out why it does not work.

My configuration is as follows:
WinNT Workstation 4.0, SP3, odbc 3.50.36.9, CTD1.5.
SQLODB32.dll is 184'320 bytes, v261.0.2.11957

I have a DSN called 'Cost98' which uses dBASE files. It works perfectly
with Access 97, but doesn't work at all with SQLWindows 32.

SQL.INI:
[ODBCrtr]
odbctrace=off
longbuffer=32000
odbctracefile=
enablemultipleconnections=off

[Win32Client]
ClientName=PGeiser-32

[win32client.dll]
comdll=sqlws32
comdll=sqlodb32

[Win32Client.ws32]
ServerPath=SqlbNT1,192.168.1.201,2155/*
ServerPath=SqlbNT2,192.168.1.202,2155/Admin,Product,Vente
ServerPath=Srv725,192.167.1.205,2155/Island,MSProxy,TestDebi

[win32client.odb32]

GUPTA.INI:
[GUPTA ODBC 32 bit DATA SOURCES]
Cost98=GPOD0000
[Cost98]
RemoteDBName=GPOD0000
ODBCConnectString=DSN=Cost98;UID=

Application:
On SAM_CreateComplete
Set SqlDatabase = 'Cost98'
If SqlConnect( hSql )

Simple. No? But it does not work.
What is the problem ?

Thank you in advance.
Patrick Geiser
Cremo SA (Switzerland)

[Sue Barruw]

Do not forget to remove any old gupta.ini files that may be causing a
problem. This file stores the ODBC information the first time it is
created and never reads it again. This can cause the problem that you
describe.

__Sue

[Carsten B. Nielsen[TAO]]

Patrick Geiser,

>Hi,
>
>I read so many articles about problems with ODBC, but still cannot find
>out why it does not work.
>

Where do you store your dBase files ? If they are on a network drive
then you need to set up the remotedbname= keyword in the [ODBCrtr]
section of the SQL.INI file.

Regards,

Carsten B. Nielsen
[TeamAssist]
ISS Data A/S, Copenhagen, Denmark
email: iss...@image.dk

[Carsten B. Nielsen[TAO]]

Patrick,

>I read so many articles about problems with ODBC, but still cannot find
>out why it does not work.
>

>bla bla ...
>
>[win32client.dll]
>comdll=sqlws32
>comdll=sqlodb32
>
>bla bla ...

>
>Simple. No? But it does not work.
>What is the problem ?
>

Many problem with ODBC come from uncorrect setup. I did a little
testing and I can reproduce your problem here now. Including the
problem with DBexplorer/ODBC you described in your private email.

Here is the needed SQL.INI entries:

Your [dbnt*sv.dll] should be:

[dbnt1sv.dll] <-- Note: SB one user engine
comdll=sqlapipe
comdll=sqlws32

Your [win32client.dll] should be:

[win32client.dll]
comdll=sqlapipe
comdll=sqlodb32

[Patrick Geiser]

Hi Neil,

Thank you for your answer.

In fact, I finally managed to make it work. I simply reordered my comdll
lines in the SQL.INI file, putting sqlodb32 before sqlws32. And it
worked. I just didn't know why it worked. Now YOU gave me the answer.
Tricky, no ? Is this topic described anywhere in the Centura
documentation ?

Many thanks,
Patrick Geiser
Switzerland

In article <365936BF...@parkwaycc.co.uk>, ne...@parkwaycc.co.uk
says...
> IIRC if you use ServerPath=.../* it inhibits further database searching,
> so it needs to be the last in the [win32client.ws32] section and
> comdll=sqlws32
> needs to be the last comdll.

[Patrick Geiser]

Hi Carsten,

Thank you very much for your answer. But unfortunately, nothing helped.

My SQL.INI file was correct, except for one little thing. The problem was
in the [win32client.dll] section, and it's totally crazy: it depends on
the way the 'comdll' lines are ordered. It just as simple as that. THANK
YOU CENTURA !!!

The following ordering DOES NOT WORK:
[win32client.dll]
comdll=sqlws32
comdll=sqlodb32

But the following ordering WORKS:
[win32client.dll]
comdll=sqlodb32
comdll=sqlws32

If you find an explanation for that, let me know.

Best regards,
Patrick Geiser.

[Subramaniam Anantharam]

Interestingly, I had asked David Burke this same question and he had
replied that order of comdll entries did not matter. But I have also seen
what you describe.

Subu
--
Subramaniam Anantharam

Patrick Geiser <pge...@cremo.ch> wrote in article
<MPG.10c3599e1...@talkto.centurasoft.com>...

[Subramaniam Anantharam]

Thanks Neil, that was an interesting document.

Subu
--
Subramaniam Anantharam

http://www.centurasoft.com/support/tech_info/knowledge_base/winsock.htm
<about:http://www.centurasoft.com/support/tech_info/knowledge_base/winsock.h
tm>

[David Burke [Centura]]

Subu,

In general, the order of COMDLL entries does not matter, but sqlws32 and
sqlodb32 do throw a wrench into the process. Hopefully the tech support
bulletin Neil references clears up the matter for you.

--
Regards, R. J. David Burke
Centura Software Corporation

Subramaniam Anantharam <Su...@EHSMED.com> wrote in article
<01be1739$4c24afc0$c10a...@subu.ehsmed.com>...

> Interestingly, I had asked David Burke this same question and he had
> replied that order of comdll entries did not matter. But I have also seen
> what you describe.
>
> Subu
> --
> Subramaniam Anantharam
>
>