Hi guys,

I have multiple db schema/databases (catalogs), both added to LLBL project, Sql Server (1) first one is main database and has no group name defined (2) second one db schema is history database, with defined "HistoryDB" Property for grouping is set to "AsSeparateProjects" (mainly because of different connection strings). I'm also using adapter mode and templates defined currently were working fine (I recently added this 2nd schema/group).

Link to screenshots: LLBL project explorer: http://screencast.com/t/eNF8ULwhrcf VS project structure: http://screencast.com/t/fhhqzsLeDr

Problems and questions: 1) generation of entities (and the stuff) seems to work fine and files are generated as expected, except DAL layer, SP calls generation code that creates SP calls in the second group although it does not have defined any (might be that templates changed to version 4.0, as they were transfered because of minor changes from previous I think version 2.6) 2) how can I use "group name" in connection string generation

public static string ConnectionStringKeyName="<[ConnectionStringKeyName]>";

gives me in DataAccessAdapter.cs ( I have 2 as expected in different namespaces) files but both pointing to the same connection key.

public static string ConnectionStringKeyName="Main.ConnectionString";

I would like to be able to specify "Main.ConnectionString.GroupName" key name if defined group name is different then empty string. As rend result would have 2 connection string keys, each for one group/db/catalog. Am I able to do that somehow?

<[RootNamespace]> property seems to have correct info in (2)

I searched SDK documentation, but didn't found this type of info, also tried with threads of similar content but aslo didn't found useful info.

Regards, K.

P.S. pardon me for my ignorance if I didn't found existing thread with the same problem

Which version of LLBLGen Pro are you using? Also Designer release date (Help/About)?

version 4.0 (May 15th, 2013), I have downloaded 4.2 but didn't installed yet. Would new version update resolve things probably? Any way, today I decided to go the other path and created new project, seems to me this is the easier way to maintain different catalogs. Although I'm just interested how that can be accomplished still (or is it possible at all).

Regards, K.

AFAIK the {$GroupName} macro (which would be the possible solution here) is not supported in the connection string key name. The designer generates only as many connection strings as different providers you have on your project (i.e. SQLServer, Oracle, etc). So it assumes that different groups connects to the same DB after all. If you are using multiple catalogs on the same server this is not an issue because each table is connected to the right catalog.

A workaround: if you set the GroupUsage setting to 'separate projects' you could create a DataAccessAdapter subclass that change at the constructor the ConnectionStringKeyName member to your desire connection string key name, for each project. Then you must use that DataAccessAdapter subclass in your own code.

Your workaround is indeed a better choice. The only advantage of having different groups ('as separate projects') over your workaround, is having all the objects 'together' in the same project.

Thank you on replay.

I had similar thing already (refering to AccessAdapter) but connecting to the same DB schema, and this is understandable.

But having GroupName constant provided in code generation would extend templating much further. (I could acomplish my thing w/o problem) In one scenario I thought, what about if I could also select schema/group upon which I would like to execute task ( and I can only select DB server, or all of them). Maybe I don't see it, but grouping except "for visual purpouses" doesn't have functionality at all. To avoid things I stumbled on, it's better concept to open new project and make new assembly set.

Regards, K.

Group can be used to visually separate items, and/or to separate them in code/projects. I'll raise your request for this feature.

Grouping in the designer is either for having a way to manage large(r) groups of entities together if they have to be in the same model or it's used to define different projects on the same target database(s).

You want to use 1 llblgen pro project with actually 2 models on 2 databases, so you group as different projects but also want to have everything separated, so why not just create two projects? The group name isn't present in the connection string as for both grouping types we have it doesn't add anything: the connection string is related to the target DB server, and it's the same for both projects.

Yes I figured that out at the end and using 2 different projects at the end. In my particular case, I thought it would be easier to maintain 1 project, but as you both stated above because of limitations it's not possible. With let say feature upgrade targeting group name usage in templates, I would be able to get that. Anyway as said above I went with 2 different projects approach.

Unfortunately I had experience with 2 same DB schema in the same project that led me to writing "overrides" of methods using AccessAdapter with 2 different constructors. I wasn't happy with that either as I had 2 same methods for entity/SP one targeting one ctor and the other 2nd one. It was too late to swap to 2 different projects as maintenance of such assembly is not quite nice as someone would expect. (at that time I was not engaged with that part of the project). And also I would add, it's not separation needed per connection string but also per transaction manager, maybe somewhere else also.

Anyway visual separation has it's usage, but project separation, I don't see it as a good, clean way, especially because of missing group name variable missing in templates. (I wanted to have "one" assembly for both different schema, as using the same on the same side, mainly going to target db, and occasionally fetching data from history db). On the other hand I could load 2 projects generated per group name (with project separation setting), I haven't tried that, so cannot say nothing pro/cons for that. At the end to me it seems better to use 2 different projects.

Thanks for clarification! K.

P.S. I don't know if it's bug but with project separation per group name, for some reason, i got few SP generated under 2nd group, where they didn't exist in DB at all. (might be the problem in template I used)

The group name is appended to the namespace, the project filename, if the grouping is set to different projects. It's also available in the templates, but not used is connectionString. You can create your own version of the template that generate the connectionString name and logic, but the logic seems to emit a connection string per schema, nor per group. There is always a way though.

Anyway, I also think that your final approach (create separate LLBLGen projects) is more suitable in your scenario.

I also think there's some confusion. This morning I realized that 'As separate projects' could mean two things: as separate LLBLGen Pro projects and as separate VS.NET projects (which is the real intention of the setting value). I think you saw it as 'separate LLBLGen Pro projects', correct? In case you did, that indeed will not match how it is implemented and look buggy. It's intended to be as separate output projects, so 1 llblgen pro project, separate output projects/code bases.

Otis wrote:

I also think there's some confusion. This morning I realized that 'As separate projects' could mean two things: as separate LLBLGen Pro projects and as separate VS.NET projects (which is the real intention of the setting value). I think you saw it as 'separate LLBLGen Pro projects', correct? In case you did, that indeed will not match how it is implemented and look buggy. It's intended to be as separate output projects, so 1 llblgen pro project, separate output projects/code bases.

yeap, you are right. I did found out that at the end

As for custom templates, connection strings, yes I modified template to adjust output to my programming skills, just by adding additional things and minor modifications. So talking about separate output, I find it useful to provide GroupName as custom variable in templates also. (Didn't get that in docs, might be that somehow I missed it)

And I think you also need it to be a parameter of the CodeEmitter task performer. This is not currently available.

It is available, on the executingGenerator, in the property ActiveSourceElementsContainerNameRaw and its CLSCompliant variant ActiveSourceElementsContainerName

See the Designer's reference manual -> GeneratorCore assembly