Conference orarep::nomahs::odbc_rdb_driver

I've taken this from an article that support wrote a while ago.  It might
give you other things to check:

Ensure the correct TCPip library is available.  If you are using
Pathworks TCPIP V2.0 with Pathworks 4.1, look for WSOCKETS.EXE in
your \windows or \windows\system directory.  This should be part of
your Pathworks TCPip distribution.

For users with DEC Pathworks V5.* and all others using a WINSOCK
compliant TCPip implementation, look for WINSOCK.DLL in the \windows
or \windows\system directory.  This file is supplied by your network
vendor.

In addition to having the correct library, WINSOCK users need to tell
SQLServices to use the WINSOCK library calls instead of the older
Pathworks calls.  This is specified in the \windows\sqsapiw.ini file.
This would be sqsapi32.ini on Windows NT.

Uncomment the line that says TCPipInterface=WINSOCK (remove the ;) and
restart Windows.

Other causes for this error would be,

    1) A corrupt WSOCKETS.EXE or WINSOCK.DLL
    2) A WINSOCK.DLL from the wrong network vendor.  (These are
       specific to the network vendor.  Be sure to get the proper
       WINSOCK.DLL from the same vendor that supplied your network
       stack)

    3) Multiple copies of SQSAPIW.DLL or SQSAPIW.INI

    4) Any memory problems that would prevent the library from being
       loaded.

NOTE:  You MUST have ODBC 1.1 or higher and/or the SQLServices
6.0 client to use WINSOCK complaint TCPip implementations.


ANALYSIS:

This error is returned when SQLServices is unable to load the proper
network drivers to establish the connection to the remote node.  In
many cases, the user is trying to connect using the TCPip network
transport.


Hope it helps.

Renee

    Renee,
    
    Thanks for the info - it's very helpful, but this customer is using
    DECnet rather than TCP/IP. 
    
    Louise.

    
    Have you checked the properties in the pathworks set-up to make sure 
    the desired node(s) are included ?  There seem to be some properties 
    you have to set up and I don't think they show up in NCP SHOW KNOWN
    NODES etc. (I haven't seen pathworks for years, but got a customer
    to have his pathworks support person check into this when he was
    getting -2003 errors).
    
    ['.1 may have been for me in 1300.* -- thanks Renee !]
    
    Regards,
    rcs
    

    I now don't think that it's the SktEndNodeEnt problem.
    
    The messages they get are:
    
    SQLSTATE S1000
    Native error code -2003
    [ORACELE][ODBC RDB] Network Suberror code -2045
    
    There's no mention of SQLSRV_DLL_ADDR_ERR in the error, so I'm
    beginning to think this is something else.
    
    MSaccess V7.0 is installed. I've seen another note (Sql_services 1932)
    with the same symptoms as this when using MSAccess V7.0 Beta. Before I
    tell them to remove Access V7.0 (they also have V2.0 installed) does
    anyone know whether this is still an issue?
    
    Getting desperate,
    Louise.

    Its been a loooong time since I configured a PW client but there are a
    couple of things I am aware of...
    
    -2045 means we cannot load a required DLL. This could be cause it was
    not there, not in the path, corrupt, lack of resources (memory), etc. 
    
    With TCP/IP, this file is usually WINSOCK.DLL but as I understand, for
    DECNET, the file is PWSOCK32.DLL. I don't know if there needs to be a
    WINSOCK.DLL also. In any case, both of these files would come from PW. 
    
    The SktEndNodeEnt problem caused a -2046 due to the missing entry
    point. The thing here is you cannot load the DLL, not that we can't
    find a routine in the DLL.
    
    So, I would pursue this from a missing/corrupt file angle... If the
    error subcode changes from -2045 to -2046, then you have the
    SktEndNodeEnt problem. 
    
    John