Suppressing NetWeaver JDBC stack traces

[Former Member]

During the boot process for my application, I check for the existence of database tables and create them if they don't exist. To do this, I look up the data source's connection pool via JNDI and then I issue a SELECT COUNT(*) FROM MYTABLE query.

When I execute this code on NetWeaver Java EE 5, a stack trace is emitted to the log whenever a table isn't found. Since this isn't an error in my case, I don't want a stack trace to be issued. It's particularly disconcerting if 20 - 30 stack traces are issued, one per table.

It appears that the stack trace is issued by NetWeaver JDBC code before my application is afforded the opportunity to handle the exception. I've tried the same code on another application server and confirmed that the stack trace isn't emitted by the database driver so it must be NetWeaver that's doing so.

Is there any way to have NetWeaver suppress stack traces for JDBC exceptions?

Thanks,

Jerry

#com.sap.sql.jdbc.direct.DirectPreparedStatement#sap.com/DSTestEAR#com.sap.sql.jdbc.direct.DirectPreparedStatement#Guest#0#####HTTP Worker [0]##0#0#Error#1#/System/Database/sql/jdbc/direct#Java#sap.com.sql.3[C0000A12B3AA000000000094017B51E800041735501B7588]##SQL error occurred on connection : code={0,number,integer}, state="", message="";
nSQL statement is "".

[EXCEPTION]

#6#208#S0002#Invalid object name 'NOSUCHTABLE'.#MYSERVER:NetWeaver:dbo#SELECT COUNT(*) FROM NOSUCHTABLE#com.microsoft.sqlserver.jdbc.SQLServerException: Invalid object name 'NOSUCHTABLE'.

at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(Unknown Source)

at com.microsoft.sqlserver.jdbc.IOBuffer.processPackets(Unknown Source)

at com.microsoft.sqlserver.jdbc.SQLServerStatement.sendExecute(Unknown Source)

at com.microsoft.sqlserver.jdbc.SQLServerStatement.doExecuteQuery(Unknown Source)

at com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.executeQuery(Unknown Source)

at com.sap.sql.jdbc.basic.BasicPreparedStatement.executeQuery(BasicPreparedStatement.java:99)

at com.sap.sql.jdbc.direct.DirectPreparedStatement.executeQuery(DirectPreparedStatement.java:307)

at com.sap.sql.jdbc.direct.DirectPreparedStatement.executeQuery(DirectPreparedStatement.java:264)

at com.sap.engine.services.dbpool.wrappers.PreparedStatementWrapper.executeQuery(PreparedStatementWrapper.java:274)

...

[adrian_goerler]

Hi Jerry,

I sugest that you use the DatabaseMeta.getTables() method to check for the existence of a particular table.

Best regards,

Adrian

[Former Member]

You're correct that I can use the metadata to determine the existence of a table. However the getTables() method is subject to interpretation by various database vendors and possibly driver vendors. On SQL Server, if I get the metadata object from a connection and then query for the existence of a table, it will only return the table if it exists in the database to which I connected (unless I explicitly specify other databases). On Oracle, it will return the table if it exists in any schema on the server unless I specify which schema I'm using. Since the connection doesn't identify the schema, I need to determine the schema before I can proceed on Oracle. Bottom line is that this technique is more susceptible to problems when you support multiple databases and drivers.

One other observation - we use the SELECT COUNT(*) technique on various other servers (JBoss, WebSphere, WebLogic) and don't see server stack traces for application SQL statements that fail. I don't understand why you need to emit a stack trace for an application SQL error before returning the exception to my code so that I can handle it.

Thanks,

Jerry