[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::odbc_rdb_driver

Title:DEC ODBC Driver
Notice:DEC ODBC Driver V2.0 Now Available
Moderator:SQLSRV::MAVRIS
Created:Tue Dec 29 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1357
Total number of notes:4864

1327.0. "win95, odbc 2.10.11, pathwrks 7.0 #49" by BROKE::BITHER () Wed Apr 09 1997 15:16

Hi,

client - ODBC 2.10.11 32 bit driver
client - Windows 95
client Pathworks/DECNet - Version 7, received less than a month ago
Server - VAX 4000/400 running Pathworks Server V5.0B
Rdb - V5.1
VMS - V5.5-2

                                                                              
PROBLEM:                                                                     

   Customer cannot make a database connection.  The error he gets is:

   SQLSTATE 1000 native error code -2003                                      
   [Oracle][ODBC][Rdb]Pathworks error #49 Can't assign requested address
                                                                              
 -2003 indicates a network problem.  In STARS it says this error            
 means the pc cannot find the host.  He says he can get to the host from 
 other applications.  In STARS it says that possibly getting to the host from 
 other applications could be due to the other apps using lat and lat is not 
 used with an odbc connection so this does not necessarily mean the pathworks 
 connection is ok.  A "show node nodename" command from the PC shows
 the node information.  I found a note where Vic Mesenzeff said if you get 
 error #49, to call pathworks. Also found in notes someone who deleted and 
 redefined the node in NCP and that fixed the problem.  Had him try this
 but it didn't work.  Still gets same error.


Meanwhile I asked him to call Pathworks support and they have given up
and cannot help him.  They also said #49 is not a pathworks error.

Until we were able to verify whether he was using the 16-bit or 32-bit
driver, I had him try replacing decnodes.dat with a version that exists 
on another working machine but this did not help.  He also tried updating
decnodes.dat using the nm5to4.exe image that he got from pathworks
support.  Then we were able to verify that he was using the 32-bit driver 
by creating an odbcrdb.log file and that means decnodes.dat is not used, right?

Gave him a STARS article entitled "Troubleshooting SQLServices -2003
Errors with DECnet"  but nothing in there helps.

One question that is really bothering the customer.  Why is the word
"server:" in the data source setup screen highlighted inside a white box
when the words "transport, class, userID, attach statement" are not?

Below are four  log files:
  SQL.LOG (The one on the Win95 machine that doesn't work)
  SQL.LOG (A log file from a Win3.1 machine that works - for comparison)
  ODBCRDB.LOG
  CLIENT.LOG


Contents of non-working SQL.LOG
--------------------------------
SQLAllocEnv(phenv00550670);
SQLAllocConnect(henv00550670, phdbc004510BC);
SQLDriverConnect(hdbc004510BC, hwnd0000074C, "(null)", -3, szConnStrOut, 255,
pcbConnStrOut, 1);
SQLError(henv00000000, hdbc004510BC, hstmt00000000, szSqlState, pfNativeError,
szErrorMsg, 511, pcbErrorMsg);
SQLError(henv00000000, hdbc004510BC, hstmt00000000, szSqlState, pfNativeError,
szErrorMsg, 511, pcbErrorMsg);
--------------------------------

Partial contents of a working SQL.LOG from a Windows NT 3.51 system
--------------------------------
SQLAllocEnv(phenv00177010);
SQLAllocConnect(henv00177010, phdbc00177880);
SQLSetConnectOption(hdbc00177880, 103, 00000014);
SQLDriverConnect(hdbc00177880, hwnd002C02CC,
"DSN=RED;UID=CMDCPROD;PWD=*******;SVR=Magic;CLS=generic;DATABASE=attach
'filename $1$dia40:[remis.prod.rdb_files]red multischema is
off';XPT=1;DBA=W;DSO=0;", 154, szConnStrOut, 0, pcbConnStrOut, 0);
SQLGetInfo(hdbc00177880, 9, rgbInfoValue, 2, pcbInfoValue);
...

*** There is no "SQLSetConnectOption" call in the sql.log on the non
working machine.  Also, the SQLDriverConnect call of the nonworking
machine has null for connect info.  


Contents of ODBCRDB.LOG
--------------------------------
Oracle ODBC 32 Bit Driver for Rdb Version         2.10.11.0.0
Oracle ODBC 32 Bit Driver for Rdb File Version    2.10.11.0.0

SQLAllocEnv                     0X004510E4
SQLAllocConnect                 0X00550ED4
SQLGetInfo                      0X00451380
...._rcSQLGetInfo                   0X0000004D
SQLDriverConnect                0X00451380
...._rcSQLDriverConnect             0X00451380
....DSN=RED                         0X00000000
...._rcSQLConnect                   0X00451380
....0X00451380: ODBCTST             0X00000000
....attach 'filename $1$dia40:[remis.prod.rdb_files]red multischema is off
....'
...._sRdbAssociate                  0X00000000
......SQL Error Code =              0X00001000
......Native Error Code=            0XFFFFF82D
....Pathworks error #49 Can't assign requested address
SQLError                        0X00000000
[Oracle][ODBC][Rdb]Pathworks error #49 Can't assign requested address
SQLError                        0X00000000

--------------------------------

Contents of CLIENT.LOG
--------------------------------
Log file generated by C:\WINDOWS\SYSTEM\SQSAPI32.DLL
Oracle Sql/Services Version 7.00

PATHWORKS NETWORK ERROR
----DECnet GETNODEENT Operation
----Pathworks error #49 Can't assign requested address
----Pathworks errno or SQLERRD[0]: 49
----                   SQLERRD[1]: 0
----                   SQLERRD[2]: 0

ASSOCIATE LEVEL LOG
----SQLSRV_RELEASE
--------SQLSRV_ASSOCIATE ID: 940078


Thanks, Diane
T.RTitleUserPersonal
Name
DateLines
1327.1M5::JHAYTERWed Apr 09 1997 16:445
>client Pathworks/DECNet - Version 7, received less than a month ago

try note 1319.  apparently we don't work with PW V7.

1327.2ThanksBROKE::BITHERWed Apr 09 1997 18:458
Thanks Jerry. 

I looked so much for pathworks v7 anywhere, I can't see
how I missed that note!  The call came in the same day as that note too!
I told the customer to use pathworks 1.0a and get the pwsock32.dll patch 
from Digital.

Thanks again, Diane