I upgraded from 2.5 to 3.0.

I converted the LLBLGen project file using the instructions and after removing the DBUtils.cs file from my .data (LLBLGen layer) project, I was able to get the solution to compile without error.

Many pages in my site work completely correctly -- but a few don't. It appears that the methods that aren't working are the FetchingUsingUC methods.

I remember in 2.5, when I upgraded the project, I had to include some additional templates to maintain compatibility with the previous version. I would like to not have to rewrite code as much as possible, so I'm wondering what templates I have to additionally include to get the FetchUsingUC methods.

CS1061: 'Data.EntityClasses.ShippingRateEntity' does not contain a definition for 'FetchUsingUCStateShippingTypeIdShippingPackageType' and no extension method 'FetchUsingUCStateShippingTypeIdShippingPackageType' accepting a first argument of type 'Data.EntityClasses.ShippingRateEntity' could be found (are you missing a using directive or an assembly reference?)

ShippingRateEntity threePack = new ShippingRateEntity(); threePack.FetchUsingUCStateShippingTypeIdShippingPackageType(TextBoxShippingState.Text, new Guid(DropDownListShippingType.SelectedValue), "3-pack");

This is type of error that I'm getting...

Any help would be much appreciated. If additional info would be helpful, let me know what additional information I can provide.

Thanks!

Please attach the llblgenproj file.

(Edit) We had a bugfix in this area recently, you should download the latest version, and try it out. Nevertheless, the methods could have been changed as well due to the breaking change that fields are now sorted by name, so methods for UCs with multiple fields could change if the names are now re-ordered alphabetically.

I downloaded the v.3.0 -- July 12, 2010. It did not fix the problem so I suspect that the sorting by name issue is at work:

This is the code that I had -- the FetchUsingUC method does not exist.

//threePack.FetchUsingUCStateShippingTypeIdShippingPackageType(TextBoxShippingState.Text, new Guid(DropDownListShippingType.SelectedValue), "3-pack");

I went in and changed the code to this (based on the method showing up in intellisense).

threePack.FetchUsingUCShippingPackageTypeShippingTypeIdState("3-pack", new Guid(DropDownListShippingType.SelectedValue), TextBoxShippingState.Text);

So, because of the different naming convention, I need to go in and rework all my calls to meet this new method name and the order of the parameters?

Or, is there an easier way to deal with this?

Thanks for your help. Timothy

Walaa wrote:

Please attach the llblgenproj file.

(Edit) We had a bugfix in this area recently, you should download the latest version, and try it out. Nevertheless, the methods could have been changed as well due to the breaking change that fields are now sorted by name, so methods for UCs with multiple fields could change if the names are now re-ordered alphabetically.

I downloaded the v.3.0 -- July 12, 2010. It did not fix the problem so I suspect that the sorting by name issue is at work:

This is the code that I had -- the FetchUsingUC method does not exist.

//threePack.FetchUsingUCStateShippingTypeIdShippingPackageType(TextBoxShippingState.Text, new Guid(DropDownListShippingType.SelectedValue), "3-pack");

I went in and changed the code to this (based on the method showing up in intellisense).

threePack.FetchUsingUCShippingPackageTypeShippingTypeIdState("3-pack", new Guid(DropDownListShippingType.SelectedValue), TextBoxShippingState.Text);

So, because of the different naming convention, I need to go in and rework all my calls to meet this new method name and the order of the parameters?

Or, is there an easier way to deal with this?

Thanks for your help. Timothy

Walaa wrote:

Please attach the llblgenproj file.

(Edit) We had a bugfix in this area recently, you should download the latest version, and try it out. Nevertheless, the methods could have been changed as well due to the breaking change that fields are now sorted by name, so methods for UCs with multiple fields could change if the names are now re-ordered alphabetically.

Ok, I rewrote all of the compound FetchUsingUC methods on one of the pages and it worked.

Is this naming structure going to change with future versions -- can I control it?

Also, can I depend on the order of the parameters from now on?

I guess I just don't quite understand the change -- but I understand how I can fix it now.

Is there an easier way than just going to each reference and changing it?

Maybe you could explain the logic and background of this change -- it would help me (and might help others as well).

Thanks! Timothy

I think you can rely on that breaking change, as from now on, as fields are now ordered by their name:

Fields have no index anymore. This leads to a problem in which order PK fields and UC fields are emitted into the method signatures. The fields are ordered by their name, ascending. This could lead to a breaking change when migrating v2.x code to v3.x when a compound PK or UC with two or more fields with the same type are used. You have to examine calls to the fetch methods using PK and UC directives as well as CTor calls to entities with a PK of 2 or more fields.

The reason this was changed is the following

In v2, an entity was mapped to 1 target in 1 database. This means that the ordinal order of the fields in the entity would be the same as the target fields in the mapped table. So if the table looked like:

ID Foo Field1 Bar

The entity fields mapped onto these fields would be in the same order.

In v3, an entity can be mapped onto multiple targets (1 target per database). this means that if you have two relational model data storages in your project (SQLServer and Oracle for example), it gives a problem if the situation is this:

SQL Server: ID Foo Field1 Bar

Oracle: BAR ID FIELD1 FOO

In which order should the fields in the entity be stored? If we pick one, or the first one, and things change, e.g. we picked 'SQL Server' and you remove that from the project, what's the order become after that?

So we decided that the order in which fields are stored is undefined: there's no ordering, other than alphabetical. So all fields used in the generated code are sorted alphabetical, ascending.

This won't change in the future, because the reason why we made this change is not going away

@Frans,

Thanks for the explanation -- that particular situation won't occur for me as I am only using Sql Server...but I understand the logic as it applies to multiple database targets.

It took me about five hours to convert my project to the new style (I was using PredicateFactory and SortClauseFactory) but I understand the logic of the changes and it makes sense.

Thanks for chiming in.

Thanks, Timothy