Greetings,

I have some code using very old version of LLBLGen (1.0.2005.1 Final) Self-Servicing. Unfortunately, it's not an option for me to upgrade the code base right now because of resource constraints.

We recently had to deal with the primary key changing types on our database from a BIGINT (which was mapped to Int64) to a Int (Mapped to Int32). This change occurred throughout the DB and all FK that linked to this primary key were also updated.

In the designer, I refreshed the model from the new Catalog. The designer properly shows both the types now as Int32 for the PK and for the FKs that related to it.

We regenerated and updated the code to reflect the type changes and everything compiles fine.

However, we now get run time exceptions when we try to access a relation member for the table who's PK changed type from a related table.

The exception SD.LLBLGen.Pro.ORMSupportClasses.ORMValueTypeMismatchException is thrown from SetupSyncClass with the detail shown below.

Additional information: The value 1 is of type 'System.Int64' while the field is of type 'System.Int32'

Here's a partial StackTrace from the generated code.

[External Code] 

Data.dll!Abode.Data.EntityClasses.StudentsEntityBase.SetupSyncClass(SD.LLBLGen.Pro.ORMSupportClasses.IEntity relatedEntity) Line 4603 C# Data.dll!Abode.Data.EntityClasses.StudentsEntityBase.SetRelatedEntity(SD.LLBLGen.Pro.ORMSupportClasses.IEntity relatedEntity, string fieldName) Line 814 C# [External Code] Data.dll!Abode.Data.EntityClasses.ClassesEntityBase.SetRelatedEntity(SD.LLBLGen.Pro.ORMSupportClasses.IEntity relatedEntity, string fieldName) Line 278 C# Data.dll!Abode.Data.EntityClasses.StudentsEntityBase.Class.set(Abode.Data.EntityClasses.ClassesEntity value) Line 7305 C# Data.dll!Abode.Data.EntityClasses.StudentsEntityBase.GetSingleClass(bool forceFetch) Line 2518 C# Data.dll!Abode.Data.EntityClasses.StudentsEntityBase.Class.get() Line 7287 C# Data.dll!Abode.Data.EntityClasses.StudentsEntityBase.ClassName.get() Line 7337 C#

When I step through the Fetch function in the EntityBaseClass (shown below):

        try
        {
            OnFetch();
            IDao dao = this.CreateDAOInstance();
            base.Fields[(int)ClassesFieldIndex.ClassId].ForcedCurrentValueWrite(classId);
            dao.FetchExisting(this, base.Transaction, prefetchPathToUse, contextToUse);
            bool fetchResult = false;
            if(base.Fields.State == EntityState.Fetched)
            {
                base.IsNew = false;
                fetchResult = true;
                if(contextToUse!=null)
                {
                    base.ActiveContext = contextToUse;
                    IEntity dummy = contextToUse.Get(this);
                }
            }
            return fetchResult;
        }
        finally
        {
            OnFetchComplete();
        }

The PK (ClassId) is of the correct type until the call to dao.FetchExisting After this line is executed, a watch on this.ClassId becomes:

'this.ClassId' threw an exception of type 'System.InvalidCastException'

I'm guessing there must be somewhere in the generated code that is not being regenerated and needs to have it's type updated--but I am at a loss to find it. Other tables PKs that started out as Int32's work fine. It's only the tables that changed from Int64's to Int32's that produce the problem.

Unfortunately, this bug is blocking a critical update for us right now, so I appreciate any prompt assistance you can provide.

Which type of database is this? What's the Designer version (release date)? And what's the LLBLGen Pro exact runtime library version number ? (please check the forum guidelines thread for more details).

Sorry--

Database is MySQL via DevArt Drivers Designer is the latest from downloads page July 6th, 2006 (1.0.2005.1)

The LLBLGen runtime library is a bit more complicated -- and maybe this is the source of my problem. I started from the version available on the downloads page--but had to upgrade to a newer version of the DevArt libraries to maintain compatibility with current versions of MySQL.

So a few years back I rebuilt the runtime libraries from source linked against DevArt dotConnect DevArt.Data.MySQL.dll 7.6.257.0 and DevArt.Data.dll 5.0.716.0 (latest versions available at that time)

~~Maybe this is my problem? ie. perhaps the newer version of DevArt maps to different data types than my older version of LLBLGen expects?

If so, is there a way I could modify the mappings--maybe similiar to what is discussed here for the Oracale provider but for MySql and for Self-Servicing?

https://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=20617&HighLight=1~~

Thinking about this further though--the mappings seem to work for other PKs of type INT that have not been changed from BIGINTs--so the above doesn't seem right.

I do recall the value returned from a mysql identity sequence to be int64 and this thus causes a problem. I'll check.

(edit) Can't find evidence of this, so my suspicion is that the value is of the type of the field, but again, not sure, it's mysql after all.

Your code suggests the value returned from the identity sequence is a 64bit value hence the problem, however the parameter created for the value has the same type as the field, so it should be int32.

Could you enable DQE tracing and see what the parameter type is ? As you're already using your own build of the runtime, you can also check this in the DQE, in the CreateSingleTargetInsertQuery method, where it creates a parameter for the identity value.

If it creates a bigint typed parameter you likely missed a field or the meta-data in the generated code is outdated, although with selfservicing that's a bit difficult as it's in the same project as the entities.