Dynaset cannot be created in Windows client if you bypass onames/tnsnames

Question

Overview: We were having a problem with slow (60 seconds) login times from our OO4O application using onames. SQL*Plus was just as slow to process a login. Using a TNSNAMES.ORA file caused the login to be almost immediate, but the solution was not acceptable in our environment, so we tried placing all of the login information (that would normally be in TNSNAMES) in the host string. That resulted in a new problem.
The problem: A login with the complete connect string specified in the host string seems to produce a restricted session. From the session, I can call a stored procedure, but cannot create a dynaset! Using the exact same parameters in TNSNAMES and the abbreviated host string, I can connect and create a dynaset (but with the 60 second delay).
The code:
BSTR bstrHost =
L�(DESCRIPTION=(ADDRESS_LIST=�
L�(ADDRESS=(COMMUNITY=tcp.world)(PROTOCOL=TCP)"
L"(Host=oursys)(Port=1529))�
L�)(CONNECT_DATA=(SID=oursys)))";
m_pOraDatabase = m_pOraSession->GetOpenDatabase(
bstrHost, L�sysuser/syspass�, 0L );
if ( m_pOraDatabase == NULL )
return FALSE;
oDynaset = m_pOraDatabase->GetCreateDynaset(
L"Select * from dual", 0);
The Failure: The m_pOraDatabase object seems to have been created OK. We can use the m_pOraDatabase object to call a stored procedure, for example. However, an exception (not a _com_errror) is generated if we try to use the m_pOraDatabase pointer to create a dynaset as illustrated in the code above.
The failure only occurs if we supply the complete host information in bstrHost. If we specify the short host name (�oursys�) forcing the lookup in onames or tnsnames, the dynaset is created normally.
Does anybody know why we cannot create a dynaset when the host information is all provided in the host string, and how to get around it?
Thanks in advance
Jerry

Answer 1

Thanks for taking a look at this.
The default domain in sqlnet.ora is world.
Since my last post, I have learned that the 'community' parameter is deprecated. I am not surprised to find a parser somewhere that bombs out looking at it. That is probably the root of the problem, as you indicated. Anyway, we are moving ahead with the workaround in place.
Thanks again
Jerry