I have a project that has been in beta and as such using a single "sandbox" library. The BO's are all mapped to tables in this library and they were the tables we wanted to update in development and testing. The library for our purpsoes was called DEVELOPMENT.

We are in a new stage of the project and the customer wants to use different libraries. I will call them PRODUCTION and TEST. He wants the BO's to map to PRODUCTION to pull the data structures and he wants the application to execute against the data in TEST. This seemed reasonable, I have plenned for this by having all my BO fills and updates flexible to take a library name from a shared property that is updateable via a menu option. This works fine for everything but the core update/add/delete functions, they are executing against PRODUCTION. I can see this in the data debug files.

It looks to me like the SF DB2 Client pulls the library name as a readonly property called TableSchema in the BO's designer file and it is indeed using PRODUCTION, which makes sense as the partial class is created by the BO Mapper which knows nothing about TEST.

So... am I right, and if so is there a workaround other than to manually update that property after each rebuild of the BO partial classes?

There's not a "quick" way to swap the "schema" (library) from one to another through the BOMapper.  It would require you to unmap and re-map each business object to the table in the new library and rebuild the partial class.

So, like you mentioned in your post, I would recommend that you fix the issue by altering the partial class by hand.  However, probably not quite in the way that you were thinking.

I would copy the property from the partial class into the main code file of the business object.  Then, I would have that property return a reference to some Shared property that you have somewhere that stores the current library.  That shared property could get the value from the registry and store it off to return it, or it could just be hard-coded to the current library.  But, it would provide a central location for you to change the library that all business objects use. 

Once you have the TableSchema property over in the main code file, when you build a business object, your code that returns the reference to the shared property won't get overwritten.  And, moving the code to the main code file has the benefit of creating a compiler error when you rebuild the partial class for a business object.  You'll have two properties with the same signature and the compiler will remind you to get rid of one of them before you can compile.  That's probably what I would do.