My database build script no longer works.

The LLBLGEN Create Script is still working fine but when I run my post-Create Script I get some errors where the Cascades I am manually adding "may cause cycles or multiple cascade paths".

I left the new options for Model First Development/Default relationship delete/update rule action at the defaults of Cascade and NoAction respectively thinking this just applied to new relationships but in Catalog Explorer, I see lots of tables where the Update Rule and Delete Rule are both set to Cascade. This looks like you are cascading deletes from supertypes to their corresponding subtype.

This is causing me problems but I can't find out where they got this setting from. They weren't 'new' relationships and even so, they set Update=Cascade rather than the default of None.

Do I have to manually go through every table in the Catalog Explorer and reset them back to None? What is to stop this happening in future.

• Did you started from DB-first and then moved to Model-First changes or just from Model-First?
• What is your LLBLGen build version?
• Please describe a list of steps to reproduce this.

Just upgrade a v3.5 project to v4.0 and it will add in Delete Cascades and Update Cascades for the entity hierarchies.

I need to turn this off but I can't find any setting. For now I have got it working by manually editing the file and deleting those attributes.

I have always used model first and just updated to v4.0 Final (June 26th)

The settings are indeed under: Project Settings -> Model First Development -> Designer Behavior:

Default relationship delete rule action and Default relationship update rule action

switch them to None, then create relational model data in the project. I can't reproduce what you're seeing: when I use the defaults (having Update rule action set to None and Delete to Cascade) and I create 2 entities with a 1:n relationship, the FK constraint created in the relational model data has as rule 'None' for update and 'Cascade' for deletes.

Could you try a 2-entity simple model with your settings (so 2 entities and a 1:n relationship) and see whether you get both rules set to cascade in teh FK constraint even though the settings are set differently?

I've seen those settings but as you say, they pertain only to new relationships. I haven't added any new relationships at all. I don't expect there to be a problem with them.

The problem I had is that the upgrade appeared to automatically add these Cascades into the Catalog Explorer for every FK relationship which was an entity subtype.

Here is a sample of the XML:

<ForeignKeyConstraint Name="dbo:Person:FK_0834d2c4ff6b62234c3ef05bb3e" UpdateRuleAction="1" DeleteRuleAction="1">

I had 33 instances like this which I manually removed.

Just reproduced the issue: 1) I took an old v3.5 copy of my llblgenproject file. 2) Loaded it in the LLBLGen 4 designer and saved it (confirming warning). 3) I clicked the "Validate model and mappings and adjust relational model data" button. 4) Diffed against the original and found 38 FK had been modified with "UpdateRuleAction="1" DeleteRuleAction="1" TrackedChanges="24"

Are these 1:m or 1:1 (probably inheritance) relation?

Walaa wrote:

Are these 1:m or 1:1 (probably inheritance) relation?

All inheritance.

It's by design, the code always chooses cascade for inheritance based FK constraints, because a PK change on a supertype should bubble down to the subtypes and cascade deletes are convenient because you can then do bulk deletes using a specific crafted query.

We didn't anticipated the error you ran into though. We'll change the way it currently creates FK constraints and will re-use the rules for inheritance based FK's as well.

Marvellous! Thanks.

Changed in next build. ALso fixed in next build: that when you change the settings for these rules, the values you pick are actually preserved

Otis wrote:

Changed in next build. ALso fixed in next build: that when you change the settings for these rules, the values you pick are actually preserved

When will this be available?

I've just added a m:n relationship, was about to check it in and I noticed that all the inheritance FK got cascades back again for both update and delete. (Just to clarify, these attributes didn't exist and were created; not existed but were changed)

I also noticed that a section called OutputSettingValues was renamed to Defaults. This is the opposite of what happened when I updated from v3.5 to v4.0. Is there a flip-flop issue here?

I currently have the July 9th build.

it will be available later today (friday). If you use an rss reader, please subscribe to: http://www.llblgen.com/Pages/RssDownloads.aspx

it will tell you when new files are available.

It's uploaded!

Otis wrote:

It's uploaded!

Thanks Frans.

I added the RSS Feed to Outlook but it didn't update. In fact, it fetched only one entry and that was from April 6th. How many feed items should it have found?

Cheers Simon

simmotech wrote:

Otis wrote:

It's uploaded!

Thanks Frans.

I added the RSS Feed to Outlook but it didn't update. In fact, it fetched only one entry and that was from April 6th. How many feed items should it have found?

You should configure your rss reader. Even if you open it in google chrome or firefox, it shows a lot of articles. I think you are watching the first (oldest). The newer right now is:

LLBLGen Pro v4.0, Full version: LLBLGen Pro v4.0 has been updated on 09-Jul-2013. Buildnr: July 9th, 2013

Didn't really work I'm afraid. - July 10th build.

Firstly, the flip-flop issue I mentioned previously of "OutputSettingValues" and "Defaults" is still there.

Secondly, whilst it uses the value from Settings to update the Rule Actions for inheritance FKs, setting them to NoAction removes that attribute from the the project file.

So I can't use Settings/ModelFirstDevelopment/Default Relationship XXX rule action as a Default for future non-inheritance relationships since they get applied back to the inheritance FKs as soon as I do a Validate Model and Mappings.

Can't you add options specifically for inheritance FKs - or persist NoAction in the attribute rather than removing the attribute?

I can't reproduce it, here it works OK. Set defaults to e.g. SetNull and SetDefault, create FKs based on inheritance (so the FK isn't there yet!), through validation, works OK: rules on the FK are set properly.

Firstly, the flip-flop issue I mentioned previously of "OutputSettingValues" and "Defaults" is still there.

Please describe exactly what you meant as no OutputSettingValues are renamed. There are 'Defaults', but you should always obtain a setting value in your template through the methods on the element, so GetRealBoolSettingValue etc. and pass in the project.

Secondly, whilst it uses the value from Settings to update the Rule Actions for inheritance FKs, setting them to NoAction removes that attribute from the the project file.

It's not in the project file as it's the default. So a default value for a given attribute doesn't emit the attribute in the project xml file. This is by design, the loader knows this.

See attached project as an example. When you select 'validate and adjust relational model data' you'll see it will create an FK constraint with SetDefault and cascade, as those are the defaults for the rules in the project setting.

Right, lets get the OutputSettingValues out of the way - that's probably the simple one.

My last save of an existing LLBLGen project renamed the "Defaults" section to "OutputSettingValues".

Before:

  <CodeGenerationMetaDataDefaults>
    <TargetElement Type="256">
      <Defaults>
        <Attributes>
          <Attribute Value="Browsable($false)" />
        </Attributes>
      </Defaults>
    </TargetElement>
  </CodeGenerationMetaDataDefaults>

After:

  <CodeGenerationMetaDataDefaults>
    <TargetElement Type="256">
      <OutputSettingValues>
        <Attributes>
          <Attribute Value="Browsable($false)" />
        </Attributes>
      </OutputSettingValues>
    </TargetElement>
  </CodeGenerationMetaDataDefaults>

Now when I look in source control at the previous save, the same section got renamed from "OutputSettingValues" to "Defaults" with only other change at the time being the addition of a m:n relationship.

The save before that was the upgrade from 3.5 to 4.0. In that the existing "Defaults" section got changed from "Defaults" to "OutputSettingValues" hence me referring to the whole thing as a flip-flop issue.

Otis wrote:

See attached project as an example. When you select 'validate and adjust relational model data' you'll see it will create an FK constraint with SetDefault and cascade, as those are the defaults for the rules in the project setting.

OK, just tried that and it created the FK with UpdateRuleAction="1" DeleteRuleAction="2" as you said. (It also changed "OutputSettingValues" to "Defaults" so its nothing to do with my particular project file)

I saved that and then went to Catalog Explorer and reset both the NoAction and saved (which showed that both attributes had been removed - presumably because NoAction has been set as the DefaultValue).

Now click 'validate and adjust relational model data' again and save and you will see that UpdateRuleAction="1" DeleteRuleAction="2" are back again.

The problem is that NoAction is removing the attribute and therefore being treated as a 'missing' value not a specific value and so your code is applying the defaults to it each time.

About the NoAction issue: good catch, this is indeed a bug that should have been addressed as well. Our XML read code has extension methods for reading 'optional attributes'. You can specify a default value if the attribute isn't available in the xml (hence: optional ), and these defaults are indeed the hard-coded ones, not the ones from the project.

Will be fixed (on Wednesday)

About the defaults/OutputSettingValues: ah, now I understand what you're referring to, at least, that it's in the project file. What I'm confused about is this: it seems you have saved in v4.0 and you got a <Defaults> section in the project file at the same place where, after you saved the project again in v4.0, you now have an OutputSettingValues section? It's important to know for us that you got the defaults in v4. From what I understand from your post it flips between OutputSettingValues and 'Defaults' (hence my confusion )

Otis wrote:

About the defaults/OutputSettingValues: ah, now I understand what you're referring to, at least, that it's in the project file. What I'm confused about is this: it seems you have saved in v4.0 and you got a <Defaults> section in the project file at the same place where, after you saved the project again in v4.0, you now have an OutputSettingValues section? It's important to know for us that you got the defaults in v4. From what I understand from your post it flips between OutputSettingValues and 'Defaults' (hence my confusion )

I have had both names appear in v4.0. And both with my project file and with the one you sent a couple of messages ago.

A section with 'Defaults' contains the default values for given elements, which are additional interfaces, namespaces and attributes. Initially they're not there, saving settings will create them. That's all. It serializes only the stuff to serialize. Please don't over-analyze the project file format, it only writes stuff it needs to remember, if it can determine data from elsewhere it won't write it.

About the fk rules (the real issue of this thread): it has nothing to do with the project file format. Resetting them in catalog explorer and then re-validating/adjusting the meta-data will set them again, so it's a bug in the code which creates the FKs.

(edit). The rules were enforced on an FK even if it was already there. In the next build, this has been corrected so they're enforced only on new FKs as that's the spec: they're defaults for new FKs. Fixed in next build (July 17th)

Otis wrote:

A section with 'Defaults' contains the default values for given elements, which are additional interfaces, namespaces and attributes. Initially they're not there, saving settings will create them. That's all. It serializes only the stuff to serialize. Please don't over-analyze the project file format

OK, I won't over-analyze

But given your answer, you think I am mentioning this because a section called "Defaults" has suddenly appeared when I saved settings. That is not the case: I am talking about the section within "CodeGenerationMetaDataDefaults" which always exists but which appears to toggle its child element name between two different names.

Here are the repro steps: 1) You sent me an LLBLGenPro v4 project file that had an "<OutputSettingValues>" section within CodeGenerationMetaDataDefault. 2) If you open the file and then click save without making any other change, that section gets rewritten but with "<Defaults>" instead. 3) If you then make a change to the Settings, for example changing the EnforcePascalCasingAlways, then click save, it changes back to "<OutputSettingValues>" again.

There may well be a good reason it does this but I can't think of one so my guess was that this is a potential bug you might want to fix.

If this is by-design then that's fine.

Reproduced. Still not sure if it has any implications on the Metadata.