Hi

I have used llblgen in the past and am evaluating llblgen pro for this application. BTW - llblgen was a great tool and llblgen pro is looking to be a fine improvement.

One issue is causing me some consternation:

I am writing a new application against an old database and have what appears to be a unique situation...

The database has a table structure is as follows:

General Tables Named As follows Table1 Table2 TableN

and

Location Specific Tables Named as follows

Location1Table1 Location1Table2 Location1TableN

Location2Table1 Location2Table2 Location2TableN

LocationNTable1 LocationNTable2 LocationNTableN

All location specific tables are the same structure as their like named counterparts.

What I would like to do is generate one generic set of these entities and pass the Location in during initialization. Is this possible?

Thanks jeff

slalom4fun wrote:

One issue is causing me some consternation:

I am writing a new application against an old database and have what appears to be a unique situation...

The database has a table structure is as follows:

General Tables Named As follows Table1 Table2 TableN

and

Location Specific Tables Named as follows

Location1Table1 Location1Table2 Location1TableN

Location2Table1 Location2Table2 Location2TableN

LocationNTable1 LocationNTable2 LocationNTableN

All location specific tables are the same structure as their like named counterparts.

What I would like to do is generate one generic set of these entities and pass the Location in during initialization. Is this possible?

You could do this yes, it's not beautiful, but it can be done (although it's a lot of work). Just create entities of the Table1-TableN type.

In SelfServicing, you can change the entity.SourceObjectName value of every field to the location you want, in a small loop (for example, do this in a utility routine). Then when you save the entity, it's saved into the right table, also delete, update etc. work. Filtering is not that easy, as filters use fields of the entity and that field will then again contain the original table name.

In adapter you have to create a derived class of DataAccessAdapter, then override the GetFieldPersistenceInfo methods and alter the data you get back to get in the proper SourceObjectName. That's about it. Adapter is a bit easier for this, as the filters will also use these routines, so you set a property you add to the derived dataaccessadapter class to the location name and with that you overwrite the SourceObjectName in the overriden GetFieldPersistenceInfo methods.