Database Connectivity Error with TD 5.1

[gqmallah]

Dear All,

I have compiled old CTD 1.1.2 working and functional code under TD 5.1 but having following error. Could you please help how to resolve this issue?

Error Number: 9293
Cannot load any communication DLLs, network may not be installed

I am using Oracle9i under Windows platform.

Your help would be appreciated.

Thanks
Ghulam

[Jean-Marc Gemperle]

Hi,

Chances is that you are using ORACLE 9.0. Since TD 5.1 SP3 you MUST use at lease ORACLE 9.2 this is because we are using NLS function in there OCI library and those fuctions aren't available on ORACLE 9.0. You can check if this is the issue by using WDEPEND ( dependency walker) against SQLORA32.DLL.
In any case make sure your CLIENTRUNTIMEDIR points where you have the TD 5.1 SQLWNTM/SQLBAPW/SQLORA32.DLL if not having it you might pickup a wrong version of our client API ( SBAPI) and this might cause invalid API version error... but in your case I believe you are using ORACLE 9.0.

Let us know

JM

[gqmallah]

Hi JM,

Thanks for the response. By the way I am using Oracle Version 9.2.0.1.0. I have modified little bit SQL.INI file and getting new error message as following:

Cannot connect Error Number 9268.

I am using following SQL.INI file in my WINNT/Windows Folder which is correctly pointing to the application.

[dbntsrv]
dbname=TBASS
servername=my-virtual2
cache=2000
sortcache=2000
readonly=0
oracleouterjoin=0
logfileprealloc=0
partitions=0
optimizerlevel=2
ansijoinsyntax=0
dbdir=C:\WINNT

[dbntsrv.dll]
comdll=sqlws32

[win32client]
clientname=TBASS
clientruntimedir="C:\Program Files\Unify\Team Developer 5.1"

[win32client.dll]
comdll=sqlora32
;comdll=sqlapipe
;comdll=sqlwsspx
;comdll=sqlntnbi
;comdll=sqlws32

[win32client.ws32]
serverpath=my-virtual2,localhost,1521


[oragtwy]
remotedbname=TBASS,@tns:TBASS
remotedbname=#TBASS,@tns:TBASS

SUBSTITUTE=SYSSQL.,
longbuffer=32760
fetchrow=2000
maperror=OFF
substitute=SYSSQL.,

Can you please have a look what is wrong in SQL.INI and where at other place?

Thanks
Ghulam

[Jean-Marc Gemperle]

Hi,

Hummm your SQL.INI looks all right to me. Just for your info when connecting to multiple back-end ie SB and ORACLE make sure sqlws32 comdll is at the end of the list else you don't connect, but here it is commented so everything looks fine... Also can you use this ( this what I always use)
remotedbname=TBASS,@TBASS
instead off
remotedbname=TBASS,@tns:TBASS

Also another though you should know that even if SQLODB32 is not listed as a comdll in the SQL.INI it gets loaded and an attempt to check the DSN is done to create a kind of a cached connection information in GUPTA.INI ( this is not documented) please make sure you don't have a DSN named TBASS if that is the case change the remotedbname to anything else, do this anyway as a test... I also see a SB DBNAME=TBASS please avoid this, I'm not sure if that could cause a problem (sqlws32.dll is commented) but I would not do that. Jsut use another remotedbname for oracle as test matter...

Originally you used to have error 9293 and you changed something to get now 9268 what did you do, maybe it gives furhter clue?

JM

[gqmallah]

Hi,

I have made following change as suggested by you:

[oragtwy]
remotedbname=TBASS,@TBASS
remotedbname=#TBASS,@TBASS

Also removed comments of the sqlws32.dll. I don't have any DSN defined in the machine. TBASS is the name of DB as well as User Name is also TBASS that's why DNAME and Client names are same i.e. TBASS

Despite above changes done in SQL.INI file problem still persists and I can not execute the application due to Database connectivity error.

Any other work around?

Kind regards,
Ghulam

[gqmallah]

Hi,

This has been tried on Oracle 11g Database also but failed with same error message Cannot connect Error Number 9268.

Regards,
Ghulam

[Jean-Marc Gemperle]

Hi,




Connectivity to ORACLE from 9.02 to 11g is working fine with TD 5.1, so there is no workaround to find but understand what is causing the problem on your environment.

I guess you missunderstood me or I wasn't clear enought for testing use ONLY the oracle router not other one. If you use both SQLORA32 and SQLWS32 make sure SQLWS32 is the last in the list, but for now just use SQLORA32 like bellow

[win32client.dll]
comdll=sqlora32


You used to have initially error
9293
Cannot load any communication DLLs, network may not be installed
This means for some reasons ( allong missing dependencies) TD cannot load the router SQLORA32.DLL
you changed something and now you have 9268...what did you change?

Use WDEPENDS (dependency walker) and drop SQLORA32.DLL it might tell us more
check the whole machine and search for ANY SQL.INI, SQLWNTM.DLL, SQLBAPW.DLL, SQLORA32.DLL, SQLNGCI.DLL ( older DLL).. IF you find any rename except in the TD 5.1 install dir...
check your system path to be set only to TD 5.1 install dir ( no other TD version in the way or SB)

Also I assume you can connect with SQLPLUSW or ie any odbc client against oracle ( on your client 9.02 machine) test of the console SQLPLUS is not relevant as it connects without the listener.

When you say you get same problem with 11g are we talking about same machine? or just connecting to a 11g database instance? if the last then this would change nothing as this is a client setup issue.

Are you on a 64bit system?

Believe me connectivity to oracle and other back-end is generaly very straitforward in TD (knowing some of the issues I mentioned) people on the forum would certainly agree with me regarding pure connectivity issue, no SQL I mean...

JM

[gqmallah]

Hi JM,

Thank you very much its working fine now. What I have done I just put two following things in comments in SQL.INI file this time.

;clientruntimedir="C:\Program Files\Unify\Team Developer 5.1"
;comdll=sqlws32


Many thanks for all help. I really appreciate it.

Kind regards,
Ghulam

[Jean-Marc Gemperle]

Hi

Greate it works for you now. If your DLLs are fine in the TD 5.1 install directory then CLIENTRUNTIMEDIR should be left in the SQL.INI this setting is very important IMO. It seems comment sqlws32 comdll is the one that fixes your issue right? I would believe because you have a DB called TBASS.

Anyway what matters is that it works!

JM