Hello,

So far I've been able to fix the problems I had from migrating from 1.0.2003.1 to the 2004 version. The last problem I got was with this line (I solved it, just wanted to share it.. :

passagers[i].ReservationDetailPassager[j].PassagerId = passagers[i].Id;

where ReservationDetailPassager reflects a table to join n:n tables Passagers and ReservationDetail. So for each entity passagers[i] of the passagers collection, I save it then I loop in its j ReservationDetailPassager entities and I used to affect to each of these the passagers[i].Id that I saved earlier. I think I used to do that because otherwise the PassagerId property of each ReservationDetailPassager[j] entity was null when I would call passagers[i].ReservationDetailPassager[j].Save(); Both passagers[i] and passagers[i].ReservationDetailPassager[j] were added to a transaction. After upgrading to 1.0.2004.1, I found out that the line above (code) had the effect of changing the flag ParticipatesInTransaction passagers[i].ReservationDetailPassager[j] from **True ** to False, so that the call to Save would result in an SQL timeout since a transaction was open and the entity wasn't saved in the same transaction - because ParticipatesInTransaction turned out to be False. So to solve the problem I just tried to comment out the line above and it worked, the Id was also automatically fetched from the parent entity (is my assumption right?)

Now I've just stumbled over another weird problem:

cargos[index].Cargo.DestinataireNom = sDestinataire;

Even though sDestinataire is not an empty string and that it contains the right value, after the execution of this line, cargos[index].Cargo.DestinataireNom is still equal to empty string. I even checked out the _entityFields collection and even there the value is an empty string. I don't understand what can cause the propety to act as if it was read only (it's not, the flag says ReadOnly = False). Any idea is welcome

Asimov wrote:

... After upgrading to 1.0.2004.1, I found out that the line above (code) had the effect of changing the flag ParticipatesInTransaction passagers[ i ].ReservationDetailPassager[ j ] from **True ** to False, so that the call to Save would result in an SQL timeout since a transaction was open and the entity wasn't saved in the same transaction - because ParticipatesInTransaction turned out to be False. So to solve the problem I just tried to comment out the line above and it worked, the Id was also automatically fetched from the parent entity (is my assumption right?)

yes. There was a bug in the original code, which didn't properly remove entities from transactions.

Now I've just stumbled over another weird problem:

cargos[index].Cargo.DestinataireNom = sDestinataire;

Even though sDestinataire is not an empty string and that it contains the right value, after the execution of this line, cargos[index].Cargo.DestinataireNom is still equal to empty string. I even checked out the _entityFields collection and even there the value is an empty string. I don't understand what can cause the propety to act as if it was read only (it's not, the flag says ReadOnly = False). Any idea is welcome

Could you step into the property set clause to see what happens really ?

Ok I'm going to step into the set code and let you know!

As for the other problem I talked about in my post, is it normal now that if I try to set the foreign key myself of an entity which is in a collection of the parent entity (like the line of code I pasted) I get weird result like the entity being removed from the transaction (what's the reason for this?) and the collection of child entities being flushed? (before the line passagers[i].ReservationDetailPassager[j].Count = 1 and after setting passagers[i].ReservationDetailPassager[j].PassagerId = passagers[i].Id, passagers[i].ReservationDetailPassager[j].Count = 0! But when I comment the line out, it works. Is the foreign key automatically assigned? I know it is when we use recursive Save (you taught me that some time ago , but in this case I'm not recursively saving (anyway I'm dealing with a collection, so recursive save doesn't work).

Yes FK's are synchronized automatically when the PK side is NOT new. This is done to avoid problems if the PK side is not saved because it is not changed

Ok I've traced into the Set code

set
            {
                if(base.SetNewFieldValue((int)CargoFieldIndex.DestinataireNom, value))
                {
                    // value set. Set related entities to null (if any), related via this field


                    OnDestinataireNomChanged();
                }
            }

after the if(base.SetNewFieldValue(... line, I checked the _currentValue private variable and it contains the good value. But when I get out of the Setter method, the value has been reset? It goes into the OnDestinataireNomChanged, but since the delegate is null, nothing is done. Then it goes back to my main code. I'm like hehe!

humm... odd

The changed event is not called which suggests the object is not used in a databinding scenario.... If you keep on stepping (thus the set clause is complete then keep on stepping) do you end up in code which resets it, or do you directly end up in your own code again?

I got back to my own code eventually without seeing anything that could reset it. But maybe when I try to watch the value once I get back the Getter method of some entity resets it?

A refetch of the entity could change it of course, perhaps that's the case, but otherwise the value should be returned by the Getter...

The entity in which I have this problem is is another entity, and it's the only place in the whole system where I have this bug. Is there any flags I could check? I didn't modify this part of the code since I upgraded to 1.0.2004.1 and it used to work fine before

Not that I'm aware of, as the behavior you're seeing simply can't happen. the only thing to check if all references to the orm support classes are indeed to the right ormsupport classes dll and the bin folder in your webapp is indeed containing the new 1.0.2004.1 version.

As you already found it, the value gets set ok but all of a sudden appears to be not correct... , so how do you check it, do you accidentily check the wrong instance?

I've downloaded the source code for the latest runtimes to try to see what's the cause for the weird behaviour, if it's me who has misused the product or something. I got ORMSupportClasses and SqlServerDQE for framework 1.1. But I'm having another problem (I swear I'm not intentionnally running into problems When I get into the Save() method of the class EntityBase,

public bool Save()
        {
            if(_fields == null)
            {
                // nothing to save
                return true;
            }

            if(!_fields.IsDirty)
            {
                // not changed
                return true;
            }

            return Save(GetConcurrencyPredicate(ConcurrencyPredicateType.Save), false);
        }

I get a Object Reference not set exception on the line if(!_fields.IsDirty). If I set a watch on _fields, it's ok (instance of EntityFields class), but the property IsDirty in it has an ArgumentException exception (and all other properties have the same exception). If I put the dlls back into my project instead of the source code, it works. Are they different? I downloaded the file RuntimeLibraries_Source_11262004.zip

Thanks!

They're not different, but if you have 2 projects in your solution and you use a different version of the same code in both projects (so the official in one and the custom build in the other) you get weird results. The IsDirty property returns a boolean member variable, so that can't be a problem. Could you check that for me, please?

Yes indeed I have 3 projects in my solution, one of those is the llbl generated project. Since the other 2 projects depend on the llbl project, if I copy ORMSupportClasses and SqlServerDQE directories to each project and remove the references to the 2 correspond official DLLs, I get an error about interfaces already declared. If I only put the source code into my 2 main projects and use the official dll in my llbl project, it runs ok but I still get "weird behaviors"