Excellent.  That format is good to know. 

FYI, when the BOMapper tries to enumerate the tables, it pulls the provider by the IBM.Data.DB2 name, so whatever ADO.NET provider is registered under that name will be used.  For instance, the client that I installed installed IBM.Data.DB2 and IBM.Data.DB2.9.1.2.  We use the IBM.Data.DB2 because according to the ADO.NET provider documentation, it will be installed with all versions of the client because it's the version-independent version of the provider.  So, we just pull the factory by name and use it.

We have fixed this issue. The connect string in the Business Object Mapper for the DB2 stucture needs to be of the following format:

Database=DSNT;User ID=USER;Password=Pwd;Server=HOST;SysSchema=SYSIBM;SchemaList=Schema

Hi Ben,

Which version of the IBM Data Provider does the Business Object Mapper use when the DB2 structure is selected?

Thanks,

Alan

Does the server have a large number of tables?  I'll see if I can change the wait window to give a status message of what table is currently being enumerated so you can see which one it's hanging on.

Hi Ben,

We traced this issue to permissions issue here. Now that the permissions issue is resolved, I have ran into a new problem. When attempting to configure a business object, the Business Object Mapper with a DB2 structure and the connect string:

Database=ValidDB;User ID=ValidID;Password=ValidPwd;Server=ValidServer;CLISchema=ValidSchema;SysSchema=ValidSysSchema

the Business Object Mapper begins enumerating tables and just locks ups. I have let it the Business Object Manager run for 5 minutes and it did not return after 5 minutes.

While you do that, I'll try to use a packet sniffer and see if it's the GetSchema() method of the DB2Connection object that's causing the problem.  If it is, I would think it would be smarter than that :|

I am not sure how to get a stack trace with your code. No exeception is being thrown. The format of the connection string being used is Database=Database;User ID=ID;Password=Pwd;Server=HOST1:5022;CLISchema=XXTEST01. One of the other developers here stated that he ran into the same problem and got around the issue by removing the CLISchema=XXTEST01 from the connection string. I tried the same workaround to the issue and then receive and object not set to an instance error.

A DBA here provided more information. The error reference

XXTEST01.SYSTABLES should be

SYSIBM.SYSTABLES

I am going attempt more permutations on the connect string to attempt to work around the problem.

I can't find anywhere where we're directly referencing SYSTABLES.  It might be coming from the call to DB2 ADO.NET Provider's Db2Connection.GetSchema() method.  Do you have a stack trace for the error?  Did you get a red exception dialog that lists the stack trace?

The error message return states that the StrataFrame app framework is looking for SYSTABLES. Our DBA's indicate that SYSTABLES do not exist on Mainframe versions of DB2 databases but do exist on Linux\Unix\Windows versions of the DB2 database. However, we are working with the Mainframe version of the database.