Is there a way to generate a single DatabaseSpecific project that will work against several DatabaseGeneric projects?

A client wishes to generate portions of a schema into a single "common" project for all shared tables and a separate project for each portion of the schema that is stand-alone. The idea being that if a stand alone library needs refreshed for one application, one would not need to refresh libraries in every application corporate wide.

If I create a project that includes the complete schema, then create a new project for each sub schema and replaced the DatabaseSpecific projects from the "sub schema projects" with the DatabaseSpecific project from the "complete schema project" would it work?

Seems like it should from a high level, but am I opening up a can of worms when it comes to maintaining it? Also can you tell the generator not to generate the DatabaseSpecific project? That would reduce the amount of code to discard and eliminate the possibility of the wrong DBSpecific project getting into the solution...

Any thoughts?

Hi Becker,

I don't think there is anything that prevents using a common dbspecific dll. As you noticed, the main task consist in merging the persistenceinfofactory. This pretty much straight forward. So, I would say yes although I never did that before. You are proposing that all yous schemas share the same access.

I think the cons would be the maintainability. If you change something (at DB or at your LGP) you have to do that with >1 projects.

It's always good to know: Why do you want it this way?

A client wishes to generate portions of a schema into a single "common" project for all shared tables and a separate project for each portion of the schema that is stand-alone. The idea being that if a stand alone library needs refreshed for one application, one would not need to refresh libraries in every application corporate wide.

The stand alone libraries would point to stand alone applications. All applications would need the "common" objects but not all applications would need the sub-objects. So if you change something that is specific to 1 application, you would not need to change all the other applications. The only time you would be required to update all applications would be when you altered the common objects.

In theory this isn't a bad idea, it just whether it maps well when using llblgen. Like I said if I could turn off the generation of the DatabaseSpecific project for the sub projects, it might not be too much extra effort.

... if I could turn off the generation of the DatabaseSpecific project for the sub projects, it might not be too much extra effort.

you can do dis from the generation dialog in the designer, go to the third tab (Task queue to execute) and disable the ones you don't need.

I don't know how common the request for this is, but it would be a great feature of the LLBLGen designer to support the notion of visual studio like "Solutions" to handle multiple projects.

Often the programmer decides how he/she wants to setup his/her solution. You could write your own template for that purpose.