Hi there,

I have a JDBC adapter service which I want to use for Batch Insertion. However, the Table name list wont really populate correctly… it only shows general schema:s and other irrelevant data. Strangely, when I connect to the SQL server through the SQL management studio GUI, I can view and access the tables correctly.

Has anyone had this problem? A theory I had was that it could be the way the user, privileges and roles are set up… but this should be a problem when accessing through the management studio as well.

Any thoughts would be highly appreciated at this point.

Ps. We’re using SQL server 2008.

Thanks in advance,

//A

Edit your connection setting, if you are using “NO_TRANSACTION”, try to use “Local_Transaction”

Thank you for replying,

I did that without any success of listing the schemas and corresponding table names. Apparently, by adding a Table Filter parameter in the “Other Properties” field under JDBC Connection Properties, the schema can be “hardcoded” i the connection… which actually resolves the issue with schema listing in the the adapter service. This is not the best way to go, because then we need to setup new adapter connections based on different schemas.

It’s a weird problem though, I must say. It seems like tables defined within the dbo schema can be listed, but not if they are in other schemas… even though the other schemas are exactly setup as dbo (with privileges and roles).

Any thoughts?

//A

Ashi,

On what version of webMethods server you faced this issue?

Also mention the version of JDBC adapter.

Hello Abhijit Yadav,

We’re running webMethods server version 7.1.2 and JDBC version 6.5.

//A

Same versions we have used for a quite long time now. We never came across this issue. We search the required schema and table from current catalogue in adapter service. Recently started using ‘other properties’ to add specific schema name for that connection to avoid changing code if schema name is changed at DB level or in case we need to refer different schema having same table structure.

Indeed, that’s an interesting way to go to have a form of “loose coupling” between DB and the code implemented. The problem we’re facing though with the schema population is here to stay it seems. I think we’re going to go with the TableFilter parameter until we migrate to v9.0.

//A