Look at SAP Note 738371 too.
1. Always test your connection using either osql or the Query Analyzer from all application servers that may be used. Testing with "SQL Server Authentication" is easy. Using "Windows Authentication" is a bit more difficult. Often you cannot logon as NT user DOMAIN\SAPServiceSID. But usually user DOMAIN\sidadm has the same privileges, and therefore you can test by logging in as sidadm, and then execute
osql -E -S<server_name>
Make sure <server_name> matches the MSSQL_SERVER setting, including the prefix (except the empty : prefix). Once you are able to connect enter "use <dbname>" where dbname matches the MSSQL_DBNAME setting.
2. You can test a connection using the following abap test program:
REPORT ZTESTDBCON.
data: DBN(128).
EXEC SQL.
CONNECT TO 'TST'
ENDEXEC.
EXEC SQL.
SET CONNECTION 'TST'
ENDEXEC.
EXEC SQL.
SELECT db_name() INTO :DBN FROM SVERS
ENDEXEC.
WRITE: / 'current database name', DBN.
Substitute TST by your DBCON name (the CON_NAME from DBCON). If SVERS doesn't exist in your database, then use any table name that does exist.This will allow you to easily monitor errors when connecting.
3. If a connection fails or takes a very long time, the first place to look for errors is in the developer trace files (SID\DVEBMGS00\work\dev_w??). The error messages will indicate which network protocol was attempted:
[DBNMPNTW]ConnectionOpen
for example means that named pipes were being used. However the trace files don't show a lot of detail beyond that. To get a more detailed trace you can do the following:
a) se38 -> Run program RSMSS_DBSL_PROFILE_SWITCH. Choose to set profiling ON.
b) Run the program that connects to the remote server and wait for it to fail.
c) Run program RSMSS_DBSL_PROFILE_SWITCH again and turn profiling OFF. Never leave the profiling on for extended periods.
Now new trace file(s) will exist in SID\DVEBMGS00\work named dbsl_w??. These files contain much more detail about the server name, and other connect options being used.
Bluesky
