We are looking again at upgrading from 2.6.

We didn't do it back in 2010 because the changes to how entities with multiple primary keys are instantiated (We have a few tables with multiple primary keys that are not necessarily in alphabetical order in the tables...)

Is there an easy way round this problem now or would we have to find all affected tables and change all references to those classes in the code?

Can we easily upgrade a 2.6 project to 4.2?

Thanks

JAmes

Are you talking about the following breaking change introduced in v.3.0?

•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.

you can keep the field order as they are in the database, there are now settings for that: http://www.llblgen.com/documentation/4.2/Designer/hh_goto.htm#Functionality%20Reference/FieldOrdering.htm

Thanks. That sounds promising.

Will I be able to upgrade existing 2.6 projects straight to 4.2?

LLBLGen Pro v4 uses the same project file format as v3: it's in XML, easy to read and is stored in files with a different extension (.llblgenproj) than in v2.x. To convert an LLBLGen Pro v2.x project, stored in a file with the extension .lgp, you have to use a conversion template using the v2.x designer.

Migrating a v2.x .lgp project to v4