Hi

On Saturday I downloaded the latest version (1.0.2004.1 Release date: 04-mar-2005) and installed it. Today, I was running through some code in my project and it suddnly started throwing error in a method that calls the 'SaveEntity' method. Let me be clear: I have not modified the code in this method in months! The code (see below) worked fine untill the new version was installed and regenerated the DAL classes..

Here's the scenario:

I have a table called "Properties" (for those of you that are curious - I have a real estate app and table "Properties" refers to land lots) which contains a field called 'RegionId' which has a m:1 relation with a table called 'Regions' which has "RegionId' as the primary key. The field "RegionId' in table 'Properties' allows NULL values. Basic stuff....

In my UI code I create on object called "CompanyProperty" which is in the business layer of my app and inherits "CompanyPropertyEntity":

Dim objCompanyProperty as CompanyProperty = New CompanyProperty(67)*

*67 = an example primary key value for a record in "Properties"

I then call the fetch method in "CompanyProperty" which simply has one line: Me.adapter.FetchEntity(Me)

No problem...

In the UI code I set the properties of objCompanyProperty based on the controls in the web form (it's a web app)..

No problem..

I then call a method called "objCompanyProperty.SaveCompanyProperty" In this method I call the 'Me.adapter.SaveEntity(Me, True)' entity method.

Before calling the 'Me.adapter.SaveEntity(Me, True)' method, however, I check and see if I need to set some fields to NULL on of which is the 'RegionId' field:

    If (Me.RegionId < 1) Then 'Flag to set NULL
           MyBase.SetNewFieldValue(CType(PropertyFieldIndex.RegionId, Integer), Nothing)
    End If

Up until Saturday the above code worked fine. Everyone is a Happy Camper..

BUT after installing the new version and generating the new DAL code, I all of a sudden got an error if the following situation happens:

If the 'RegionId' field is originally NULL and I my above code still hits the line "MyBase.SetNewFieldValue.." I get the following error:

"An exception was caught during the execution of an action query: UPDATE statement conflicted with COLUMN FOREIGN KEY constraint 'FK_Properties_Regions'. The conflict occurred in database 'AFGRentals', table 'Regions', column 'RegionId' "

It seems the update query is trying to update 'RegionId' in the 'REGIONS' table on NOT the Properties table!!!

???? Go figure!!!!!!!

I uninstalled the latest version and reinstalled the prior version I was using (1.0.2004.1 - Released Sept 24, 2004.. (I think whatever the version was last availble for download last December..)

And "VIOLA!" The above code is back to normal - NO errors!!!!! The code can set field 'RegionId' in table "Properties" whenever the situation needs to..

Otis - can you address this probelm?

Thx Steve

Please post some code which illustrates the actions you're doing. It can't be you save a property entity and a region entity gets updated, that's impossible, so it might be the property has a region entity set as a referenced entity and because you're saving recursively, that entity is saved as well.

There was a bug in teh SetNewFieldValue routine which didn't update fields correctly in some situations. It is likely your software worked OK with that bug but fails now, however that's solveable, though I need to see the routine you're executing so I can give you the proper advice what to change where

I do find the adapter instance inside an entity object interesting. You wanted selfservicing but used adapter, could you (if you have the time) elaborate a bit why you did this? (so it gives me some insight why some users do some things with the generated code so I can anticipate on it in the future)

Thx for replying..

OK - here's the scenarion from the top down..

Soltion contains 2 projects:

1) ASP.Net project (references BusinessFacade) 2) BusinessFacade (references LLGen DLLs - adapter way)

The UI web form code is as follows (abbreviated, of course!):

Imports e_foresight.BusinessFacade

Public Class UC_PropertiesManage

 Private Sub btnSave_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnSave.Click

    Try
    
'//// abreviated......

            'Are we adding or modifying? (Note! i is PropertyId)
            If (i.Equals(-1)) Then
                'Adding
                Me.objCompanyProperty = New CompanyProperty
                ExitMessage = "added sucessfully!"
                LogMessage = "New property added (PropertyId: "
                'Trip flag
            ElseIf (i > 0) Then 'Modifying
                'Set & fetch object
                Me.objCompanyProperty = New CompanyProperty(i)
                Me.objCompanyProperty.FetchCompanyProperty()
                ExitMessage = "modified sucessfully!"
                LogMessage = "Property modified (PropertyId: "
            Else
                'Something funny is going on
                Throw New System.Exception("Invalid value paramers passed in attempting to save property information")
            End If

            '////////////////////////////////////////////
            'Set object property values
            Me.SetCompanyPropertyProperties(blIsNew) * See below
            '///////////////////////////////////////

    '/////////Save to db////////////////////////////////
            Me.objCompanyProperty.SaveCompanyProperty(Me.PropertyItemsListCollection, _
                                                          Me.PropertyIncludePricesListCollection, _
                                                          Me.PropertyOptionalPricesListCollection, _
                                                          Me.PropertyPermissionsListCollection, _
                                                          arrPropertyDescription, Me.OriginalNumSleeps, _
                                                          Me.SetExpiresDaysToNull)
            '///////////////////////////////////////////////////



'////////......

      Catch ex As Exception
            'This is not a fatal error, so log & show message
            Dim ErrorLog As New ErrorLog
            ErrorLog.SaveNewError(ex.Message, "btnSave", "UC_PropertiesManage (" & ex.Source & ")", MyBase.CurrentUserInfo.AdminUserId)
            ExitMessage = AppConstants.NonFatalErrorMessage
            Me.EnableControls(False)
            Me.ResetFormControls()
        Finally
            'Set label to show because just modifying login
            Me.lblInfo.ForeColor = lblInfo.ForeColor.Red
            Me.lblInfo.Visible = True
            Me.lblInfo.Text = ExitMessage
        End Try

End Sub

 Private Sub SetCompanyPropertyProperties(ByVal IsNew As Boolean) As CompanyProperty

'//// abreviated......

Me.objCompanyProperty.RegionId = Convert.ToInt32(Me.cboRegions.SelectedValue)

(Note! Me.cboRegions is a drop down list... If first entry "select region" is selected a value of -1 is set, otherwise the RegionId from table "Regions" is set)

'///...............

End Sub

private m_CompanyProperty as CompanyProperty

    Private Property objCompanyProperty() As CompanyProperty
        Get
            Return m_CompanyProperty
        End Get
        Set(ByVal Value As CompanyProperty)
            m_CompanyProperty = Value
        End Set
    End Property


End class

------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------

in businessfacade (CompanyProperty.vb):

Imports System.Runtime.Serialization
Imports e_foresight.DAO
Imports e_foresight.DAO.EntityClasses
Imports e_foresight.DAO.DatabaseSpecific
Imports SD.LLBLGen.Pro.ORMSupportClasses
Imports e_foresight.DAO.FactoryClasses
Imports e_foresight.DAO.TypedListClasses

Public Class CompanyProperty
      Inherits PropertyEntity

 Private adapter As DataAccessAdapter = New DataAccessAdapter

    ''' <summary>
    ''' Gets a property object entity 
    ''' </summary>
    Public Overridable Function FetchCompanyProperty() As Boolean
        Return Me.adapter.FetchEntity(Me)
    End Function

 ''' <summary>
    ''' Save customer object - transaction
    ''' </summary>
    Public Sub SaveCompanyProperty(ByVal PropertyItemsListCollection As KeyValueCollection, _
                                       ByVal PropertyIncludePricesListCollection As KeyValueCollection, _
                                       ByVal PropertyOptionalPricesListCollection As KeyValueCollection, _
                                       ByVal PropertyPermissionsListCollection As KeyValueCollection, _
                                       ByVal PropertyDescriptionArray As PropertyDescription(), _
                                       ByVal OriginalNumSleeps As Byte, ByVal SetExpiresDaysToNull As Boolean)
        
        Try

         '//// abbreviated..

            ' Here we set nulls if need be...
            If (Me.RegionId < 1) Then
                MyBase.SetNewFieldValue(CType(PropertyFieldIndex.RegionId, Integer), Nothing)
            End If
            '
              '//// abbreviated..

            '//////////////////////////////////////

            'Start transaction
            Me.adapter.StartTransaction(IsolationLevel.ReadCommitted, "ModSaveProperty Trans")

            'Save property object
            Me.adapter.SaveEntity(Me, True)


          '///// abbreviated...


            'All OK so commit to db
            Me.adapter.Commit()

        Catch ex As Exception
            Me.adapter.Rollback()
            'Bubble up so we can handle in UI
            Throw New System.Exception("Modify/Save property object failed in method 'SaveCompanyProperty'. Rollback successfull - Cause: " & ex.Message)
        Finally
            'Clean up
            Me.adapter.Dispose()
        End Try
    End Sub


   ' /// <summary>
    ' /// The RegionId property of the Entity Property
    ' /// </summary>
    Public Overrides Property [RegionId]() As System.Int32
        Get
            Return MyBase.RegionId
        End Get
        Set(ByVal Value As System.Int32)
            MyBase.RegionId = Value
        End Set
    End Property

End Class

Any more need code I will post if need be..

Steve

If the 'RegionId' field is originally NULL and I my above code still hits the line "MyBase.SetNewFieldValue.." I get the following error:

"An exception was caught during the execution of an action query: UPDATE statement conflicted with COLUMN FOREIGN KEY constraint 'FK_Properties_Regions'. The conflict occurred in database 'AFGRentals', table 'Regions', column 'RegionId' "

It seems the update query is trying to update 'RegionId' in the 'REGIONS' table on NOT the Properties table!!!

I've checked this, and if I do:

UPDATE orders 
    SET Customerid = 'SOLDE'
where orderid=10254

In northwind, I get: UPDATE statement conflicted with COLUMN FOREIGN KEY constraint 'FK_Orders_Customers'. The conflict occurred in database 'Northwind2', table 'Customers', column 'CustomerID'.

which is typical, as it can't find SOLDE in the customers table. In your case: some value is saved into Properties.RegionID, which violates the FK and isn't found in Regions.

Ok, so now we've to find out what value is written into Properties.RegionID and why. Could you check for me please what MyBase.SetNewFieldValue(CType(PropertyFieldIndex.RegionId, Integer), Nothing) returns? It should return true.

Then, after that line, what's the value of: Me.Fields("RegionId").CurrentValue Me.Fields("RegionId").IsChanged

?

[quotenick="Otis"]

Ok, so now we've to find out what value is written into Properties.RegionID and why. Could you check for me please what MyBase.SetNewFieldValue(CType(PropertyFieldIndex.RegionId, Integer), Nothing) returns? It should return true.

Then, after that line, what's the value of: Me.Fields("RegionId").CurrentValue Me.Fields("RegionId").IsChanged ?

Otis - I would be more than happy to check for you.

However, I can't because I had to uninstall the new version and reinstall the previous version I was using to be able continue work on the app I'm getting paid to do...

I simply don't have the time to go and uninstall the previous version that works for me, reinstall the new one, check the above, uninstall new version, then reinstall current working version to be able to get back to work. The man that signs my paycheck would frown on this. Especially because he's not a programmer and he shelled out the $$$ to buy LLGen. He simply wants things to work and results to had - I'm sure you understand the position I'm in...

If you want me to check above with the older version I'm using now - no problem. Just let me know...

Steve

I understand your position, but I can't help you in that case either, if I don't have the proper info. The older version of course works as expected, otherwise you would get the exception there too

THough if you would run the tests with the old code it would still be helpful: -> What I do know is that there were some issues with the code in SetNewFieldValue, when it comes to setting existing entity's fields to null if the original value was also null. It then still did set the value to null again, effectively changing the field. In the new code it doesn't do that.

I can't quite grasp the scenario in which this would cause an FK violation though. What you should do in ANY CASE is de-referencing a referenced Region entity if RegionId is set to NULL, so set Me.Region to Nothing.

Hi

This weekend, when I have a bit of time, I will run the tests you asked for - both on the older current version, and on the new version. It seems to me, however, that this problem should be easy to replicate on any machine even using the NW database as a test db. If the problem lies in:

Otis wrote:

What I do know is that there were some issues with the code in SetNewFieldValue, when it comes to setting existing entity's fields to null if the original value was also null. It then still did set the value to null again, effectively changing the field. In the new code it doesn't do that.

then it should pop up on your test machines, especially if you replicate the code I mentioned above. If you look at the documentation - you will see that what I'm doing is exactly what the documntation says to do in setting a null value....

Steve

(original message deleted as the testcase was wrong).

my new testcase:

[Test]
public void InsertNullTest()
{
    using( DataAccessAdapter adapter = new DataAccessAdapter())
    {
        EmployeeEntity newEmployee1 = new EmployeeEntity();
        newEmployee1.Name = "Frans Bouma";
        newEmployee1.EmployeeSince = DateTime.Now;
        newEmployee1.TestRunId = _testRunID;

        // add other employee.
        EmployeeEntity newEmployee2 = new EmployeeEntity();
        newEmployee2.Name = "John Doe";
        newEmployee2.EmployeeSince = DateTime.Now;
        newEmployee2.ManagedByEmployee = newEmployee1;
        newEmployee2.TestRunId = _testRunID;

        Assert.IsTrue(adapter.SaveEntity(newEmployee1, true));
        Assert.IsFalse(newEmployee1.IsNew);
        Assert.IsFalse(newEmployee2.IsNew);
        Assert.IsTrue(newEmployee1.TestOriginalFieldValueForNull(EmployeeFieldIndex.ManagedBy));
        Assert.IsFalse(newEmployee2.TestOriginalFieldValueForNull(EmployeeFieldIndex.ManagedBy));

        // set to null
        Assert.IsTrue(newEmployee2.SetNewFieldValue((int)EmployeeFieldIndex.ManagedBy, null));
        Assert.IsNull(newEmployee2.Fields[(int)EmployeeFieldIndex.ManagedBy].CurrentValue);
        newEmployee2.ManagedByEmployee = null;

        Assert.IsTrue(adapter.SaveEntity(newEmployee2, true));
        Assert.IsTrue(newEmployee2.TestOriginalFieldValueForNull(EmployeeFieldIndex.ManagedBy));

        // now we have an entity which has null in the ManagedBy field. 

        // set to -1 first. to flag that we have to set it to null later on.
        newEmployee2.ManagedBy = -1;

        // ...
        if(newEmployee2.ManagedBy==-1)
        {
            // set to null
            Assert.IsTrue(newEmployee2.SetNewFieldValue((int)EmployeeFieldIndex.ManagedBy, null)); // A
            Assert.IsNull(newEmployee2.Fields[(int)EmployeeFieldIndex.ManagedBy].CurrentValue);
        }

        Assert.IsTrue(adapter.SaveEntity(newEmployee2, true));
        Assert.IsTrue(newEmployee2.TestOriginalFieldValueForNull(EmployeeFieldIndex.ManagedBy));
    }
}

fails at line A. Which is the situation you're in.

Ok, bug #158, fixed on 23-feb-2005: When a field F is set to NULL, using entity.SetNewFieldValue(), and that field was already NULL in the database, the field is set with a value and thus marked as changed, which causes the query to set the field in the database, probably triggering triggers and default constraints.

This is your situation. The RegionID is NULL, you then set it to -1 to set it to NULL later on again. Though as the field is already NULL in the database, it shouldn't be set to NULL again, as that would make the record 'changed', causing triggers to fire (if any) and timestamps to be updated (if any) and nothing really changed.

Solution: Change:

Me.objCompanyProperty.RegionId = Convert.ToInt32(Me.cboRegions.SelectedValue)

into:

Dim regionValue As Integer = Convert.ToInt32(Me.cboRegions.SelectedValue)
If Not (regionValue = -1 And Also Me.objCompanyProperty.TestOriginalFieldValueForNull(PropertyFieldIndex.RegionId)) Then
    Me.objCompanyProperty.RegionId = regionValue
End If

or better: track the setting of NULL of regionId in another variable (i.e.: not the field). You now overrided the property RegionId, which is not necessary as it is already in the base class.

Steve, I'd appreciate it next time you run into a bug or issue, to see if you can write a representative case which shows the issue, or at least try to work with me fixing these things by providing more runtime info. It is very hard to track down the exact execution flow of your application from here, and for me it's very frustrating to spend a lot of time trying to figure out what probably is going on in your application using just a few clues, writing testcases which don't work or don't represent the situation of your application, because I DO want to have bugs fixed a.s.a.p.

Thinking about it, it's probably wise to reset the value back to the value set, but also set IsChanged to false. I'll add that fix to 1.0.2004.2. Can't... it can't undo change flags and databinding events already fired. Left as is.

Otis

I've been using LLGEN for a year and have been very happy with both the program & the quick help you always provide.

But this time, I am a bit pissed off. One - I'm a year into a project with LLGen, my project consists of 43 tables. Al ot of these tables have similar fields that have lookup tables that are exactly like the "Regions" look up table used as the example above. The bug situation discussed is countless lines of code. You are asking me to go back into my project now and do a workaround:

Dim regionValue As Integer = Convert.ToInt32(Me.cboRegions.SelectedValue)
If Not (regionValue = -1 And Also Me.objCompanyProperty.TestOriginalFieldValueForNull(PropertyFieldIndex.RegionId)) Then
    Me.objCompanyProperty.RegionId = regionValue
End If

for every entity that that might have a origianll null value being set to a null value.

That's <b>CRAP!</b> Not only is this the second time a bug "fix" has broken my code (see "[SOLVED] HUGE problem - Need a work around") to which you replied:

Otis wrote:

Your code relies on a bug, and I'm sorry, but I'm not going to undo a fix there is no need for that either, here's how.

OK - I bit the bullet on that one and spent a couple of hours redoing code to be compatible with the new version. But now, I'm even deeper into my project which would mean even more code adjustments. And even MORE important is the face that the <b>DOCUMENTATION</b> says to do it <b>EXACTLY</b> how I did it. This is a BUG in YOUR new code which should take into account the situation mentioned above.

And the AUDACITY of you to say:

Otis wrote:

Steve, I'd appreciate it next time you run into a bug or issue, to see if you can write a representative case which shows the issue, or at least try to work with me fixing these things by providing more runtime info

I practically wrote a book giving you every routine and describing in detail the situation. Then you complain because I didn't provide runtime info you. I've been working for almost 10 years in app development and not one company I've worked for has asked a customer to provide more than a detailed description of what they were doing when a problem occured. It was up to us to play user and replicate the scenario and go from there. You can't expect users of your app, which are developing production apps, to go take time and set up a test scenario just to save YOU time. People are PAYING YOU for your program not the other way around.

And what I'm most pissed about is this:

Otis wrote:

Thinking about it, it's probably wise to reset the value back to the value set, but also set IsChanged to false. I'll add that fix to 1.0.2004.2. Can't... it can't undo change flags and databinding events already fired. Left as is.

WHAT??? YOUR not going to fix it?????? WHAT????? You even admited there was a bug:

Otis wrote:

When a field F is set to NULL, using entity.SetNewFieldValue(), and that field was already NULL in the database, the field is set with a value and thus marked as changed, which causes the query to set the field in the database, probably triggering triggers and default constraints.

Are you saying that just because I used your code in a situation that you <b>OBVIOUSLY</b> overlooked in development, that you are saying "Oh well, such is life... no can do now because then I will have to redo my code that I thought I fixed to start with. "?????

<b>COME ON!!!!</b> That, from a professional stand point is WEAK!!! Very WEAK!!!

In the past year I have talled very highly to other programmers about LLGEN. No more, in fact, I seriously will have to consider using LLGEN in future projects..

Steve

Stoop wrote:

Otis I've been using LLGEN for a year and have been very happy with both the program & the quick help you always provide.

But this time, I am a bit pissed off. One - I'm a year into a project with LLGen, my project consists of 43 tables. Al ot of these tables have similar fields that have lookup tables that are exactly like the "Regions" look up table used as the example above. The bug situation discussed is countless lines of code. You are asking me to go back into my project now and do a workaround:

Dim regionValue As Integer = Convert.ToInt32(Me.cboRegions.SelectedValue)
If Not (regionValue = -1 And Also Me.objCompanyProperty.TestOriginalFieldValueForNull(PropertyFieldIndex.RegionId)) Then
    Me.objCompanyProperty.RegionId = regionValue
End If

for every entity that that might have a origianll null value being set to a null value.

That's <b>CRAP!</b>

Please, be reasonable here. You track that you have to set a field to NULL again in the property. I advice you now not to do that and it's 'crap'.

Not only is this the second time a bug "fix" has broken my code (see "[SOLVED] HUGE problem - Need a work around") to which you replied:

Otis wrote:

Your code relies on a bug, and I'm sorry, but I'm not going to undo a fix there is no need for that either, here's how.

OK - I bit the bullet on that one and spent a couple of hours redoing code to be compatible with the new version. But now, I'm even deeper into my project which would mean even more code adjustments. And even MORE important is the face that the <b>DOCUMENTATION</b> says to do it <b>EXACTLY</b> how I did it. This is a BUG in YOUR new code which should take into account the situation mentioned above.

No, the issue you run into is because you track the -1 in the property. If you track it in another variable it works.

The -1 makes the field change, and the check in the SetNewFieldValue() routine to see if it has to set a field to a value or not, currently checks for null/Nothing values if the DbValue is null/Nothing, and if so, it doesn't set the field. This is the fix for thsi bug:

Otis wrote:

When a field F is set to NULL, using entity.SetNewFieldValue(), and that field was already NULL in the database, the field is set with a value and thus marked as changed, which causes the query to set the field in the database, probably triggering triggers and default constraints.

The issue isn't that you do something the documentation says you should and that breaks, the issue is that you set the -1 in the property RegionID. This makes the RegionID property 'changed', and thus the entity 'changed'. You then set it again to null. If you had tracked this differently you wouldn't have had this problem.

I already explained why I fixed the bug with the null values: it will give side effects which are unexpected. Unfortunately, the fix for that bug makes your code not work correctly.

So what should I do: not fix the original bug and effectively keep a bug in my code so your code works as planned, or fix the bug because a bug is in the code and it will hurt your code in some ways?

Now, when I fix a bug, it can be the fix doesn't cover all the possible scenario's. To find that out, the scenario which isn't covered, has to be properly defined, otherwise I can't make a better fix. This isn't silly code Steve, it's rather complex what's going on behind the scenes, so defining all possible scenario's can be tricky at best.

Your particular situation is similar to: the field is 3, you set it to 4, 5, 6, 10, and again 3 and the last 3 isn't set, because the field is already 3 in the DB. However, the code does allow you to do that. So what I have to change to my fix for that bug I mentioned earlier, is that I have to check if the field is already changed, and if so, set it with whatever comes in. That would make the situation: NULL, set it to -1, 3, 10, 42 and again NULL the same as 3, 4, 10, 42 and again 3.

However, coming to this conclusion wasn't easy, as I had no information about runtime data, I had to guess what your situation was. My first unittest wasn't correct as it succeeded. It was only when I explained the issue here internally I found out that my test might not be correct, so I tried another one (as I didn't have any runtime info, I had to guess how your program flowed) and luckily I made one which mimiced the same issue, at least that's what I assume, but I'm nowhere sure it does.

I'll now comment on your posting, which I find way out of line. I'll say you misunderstood me, though keep in mind that I won't hesitate to ban you from this forum and support if you continue with this hostile behavior. I'm here to help you and I'm more than willing to do that, but there are situations where I draw the line and will say: "no more". You are close to that line, Steve. This whole posting costed me already a lot of time and I can better spend that on fixing your issue, or do you think my time is better spend on countering your out-of-line flames ?

And the AUDACITY of you to say:

Otis wrote:

Steve, I'd appreciate it next time you run into a bug or issue, to see if you can write a representative case which shows the issue, or at least try to work with me fixing these things by providing more runtime info

I practically wrote a book giving you every routine and describing in detail the situation. Then you complain because I didn't provide runtime info you. I've been working for almost 10 years in app development and not one company I've worked for has asked a customer to provide more than a detailed description of what they were doing when a problem occured.

You haven't? Ever tried to get a bug across to microsoft? Or a random control vendor? If you cant provide a working example they won't even listen to you.

As an example of what I mean: I did wrote a unittest which worked and thus didn't show the issue you ran into at all. Because I didn't have any runtime info I didn't know what was wrong in your case. What am I suppose to do then, Steve, spend 10 hours to try every possible scenario or ask you to provide 2 simple booleans? Why is that so much to ask? It would greatly help me and thus help you. I don't see why it is so much to ask you 2 simple values.

It's as if asking for a stacktrace for an exception is too much and I have to figure out myself what's going on.

It was up to us to play user and replicate the scenario and go from there. You can't expect users of your app, which are developing production apps, to go take time and set up a test scenario just to save YOU time. People are PAYING YOU for your program not the other way around.

I think you see it wrong. I am more than willing to spend an entire day to fix your problem (and I regularly do for various customers, Steve) as long as I have enough information work work with. If I have to 'guess' what the runtime information is, I can't properly help you, that's why I asked for more information. I don't see why that's a problem, it will only help you, as I then can try to reproduce it here with proper testcode. No-one is helped by a fix based on a guessed situation, it might not help you and it might cause other problems as well.

And what I'm most pissed about is this:

Otis wrote:

Thinking about it, it's probably wise to reset the value back to the value set, but also set IsChanged to false. I'll add that fix to 1.0.2004.2. Can't... it can't undo change flags and databinding events already fired. Left as is.

WHAT??? YOUR not going to fix it?????? WHAT????? You even admited there was a bug:

Otis wrote:

When a field F is set to NULL, using entity.SetNewFieldValue(), and that field was already NULL in the database, the field is set with a value and thus marked as changed, which causes the query to set the field in the database, probably triggering triggers and default constraints.

Are you saying that just because I used your code in a situation that you <b>OBVIOUSLY</b> overlooked in development, that you are saying "Oh well, such is life... no can do now because then I will have to redo my code that I thought I fixed to start with. "?????

Huh? This bug:

Otis wrote:

When a field F is set to NULL, using entity.SetNewFieldValue(), and that field was already NULL in the database, the field is set with a value and thus marked as changed, which causes the query to set the field in the database, probably triggering triggers and default constraints.

IS fixed. I FIXED this bug. The FIX is causing you a problem because you TRACK 'I have to set this variable to null later on' in the property, effectively changing its value.

After this tiresome discussion I found a discrepancy between two situations and I can fix that easily for you, if you still want me to, as making the two situations alike and behave teh same, which will solve your problem and not effect other people's software. IMPORTANT I did find this solution 20 minutes ago, after re-re-re-reevaluating your situation and thinking about other situations which are alike. The remark I posted and you quoted was about a quick fix I though would solve it: 'reset the IsChanged' flag. Though that can't be done and I'll explain below.

The reason I can't reset the IsChanged flag and the reason why I posted that remark (!) is that whenever you change a property, say property.RegionID=-1, the RegionChanged event is fired, the entity is marked changed, the field is marked changed, the EntityChanged is fired, the collection the entity is in fires an event etc.

UNDOING that changed flag is not possible, I can't undo the RESULTS of the events fired, like what a grid does when an event is arriving. So I simply couldn't unset the IsChanged flag and because of this reason I said: I can't fix this (i.e.: that way, resetting the IsChanged flag). If I could I would, but I can't. I can of course set the IsChanged flag to false, and it MIGHT work in your situation, but it also MIGHT NOT, because it will cause that the object and the bound controls are out of sync. So another customer might say (correctly) that there is a bug and demand a fix because his code breaks after this IsChanged flag reset.

I can fix it on another way, but that didn't occur to me until 20 minutes ago.

<b>COME ON!!!!</b> That, from a professional stand point is WEAK!!! Very WEAK!!!

I'm willing to go very very far in helping any customer, you get high level professional support here, so don't come to me that I'm not professional in this, because that's very very low and unfair. I fix EVERY bug that's reported if it can be fixed, and NO-ONE has to pay a dime for that update, you don't have to have a subscription, you don't have to wait 3 years for a new build or service pack, you'll get it the same minute I created a fix if you want.

You get updates for free which also contain fixes for design flaws and correct design bugs, something every competitor asks money for. You also don't have to pay (extra) for support nor do you have to pay for 'support' cases, like with Microsoft.

In almost all cases you don't have to provide ANY testcase, only if I really can't figure out what's going on and I need the help of the person who reported the issue. Apparently that's unprofessional and too much to ask for.

I'll tell you, Steve, I draw the line right there. I am more than willing to help any customer, but if they don't want to help me help THEM, I can't help them.

In the past year I have talled very highly to other programmers about LLGEN. No more, in fact, I seriously will have to consider using LLGEN in future projects..

It's up to you if you don't want LLBLGen Pro anymore in your projects. I think you draw conclusions based on false assumptions and misunderstandings and there are more than 10,000 postings on this forum proving you're wrong in this. I don't expect anything from you, just to be polite, as I try to be as polite as I can be towards you, and that you try to help me help YOU. If you don't want to do that, then I'm sorry, but in that case I can't help you either. I hope you understand that.

I'll update the runtime libraries and will upload a hotfix. I also won't tolerate any more of this below the belt postings from you, Steve, or your access to this forum and our support channels will be blocked. I hope we understand eachother.

Otis

I never complained about your support. In fact, I mentioned that I have been always happy with it.

But I do feel that I have a valid point. If you feel that what I wrote above is flame & "crossing the line", well, OK - your the moderator & that is your decision. From my point of view, however, it wasn't a flame - I simply was airing why I was upset, and I still feel I have every right to do so. I never questioned your dedication to applying yourself to fixing issues. Nor, did I EVER expect you to trouble shoot my code. My code wasn't the issue - it only exposed a problem with the new version code. Don't forget - the key "SetNewFieldValue(CType(EntityFieldIndex.EntityField, Integer), Nothing)" in LLGen is the problem, that's what broke. My code has been in place for months and it followed exactly how the documetation said to do in setting a field to NULL and it worked fine until I ugraded to the new version. THEN it broke. Then you asked me to write business logic into prexisiting code as a workaround to something that shouldn't have broke in the first place.

Speaking of flaming, don't you think it is a bit of a flame when you called my code "crap"? You have no idea of the what my app needs to be able to do based on the UI. Did it ever occur to you, that LLGen code might be wrapped in business logic that is used by several apps so I had to write the code the way I did? Or maybe some folks are using LLGen in web apps not Windows so they don't have the luxery of databinding? You may not agree with my logic, which is cool, but the bottom line is still the problem in the LLGEN method, not my code.

Lastly, you mentioned that by "fixing" the SetNewFieldValue" method so it works for me, might break someone else's code.. Well, that's a backward compatibilty issue. Not only with me, but with everyone using LLGen in ways you probably never occured to you in development. You said yourself that:

I can fix it on another way, but that didn't occur to me until 20 minutes ago.

Well, Okay - now you got a fix. But would that fix ever have occured to you had not someone pointed it out and then spent the time looked at the issue more carefully? If it wasn't me - I gurantee it would have been some else that would have mentioned something sooner or later.

'Nuff said. I won't say anymore. I would be happy to continue this out of the forum, as I'm still a bit irked and I still feel I have more than a valid point. You may not agree, and that's cool, and I respect that. But I won't back down on what I wrote before - so if you want to ban me - do what you have to do.

Meanwhile, when you get the fix up, I will test it, even if it means uninstalling the LLGEN version that I know works on my production app, installing the new version + hot fix and testing. That I will do - and report back with the results.

Steve

This forum has been a huge help to me, Otis, you have provided EXCELLENT support. I know I have gotten help on things that Otis DID NOT have to provide support for. Seriously, for the 200 and some bucks that our company paid for this, we have gotten every penny plus some out of this!

If you are worried about this breaking your production code, have you considered using source control? Maybe forming a new branch for different versions? You could even revert back to an older version if possible. Do you unit test your code? Are you using a logging framework to catch all debug information? Check out log4net for logging, and subversion for a version control system.

The only thing that turns me off LLBLGen is using it with webservices (which isn't Otis's fault ). Even then I found a workaround so I could still use this great tool.

Oh one more thing: Answer and I both had to go over code and fix things after bugfixes. I would be much happier getting bugfixes that require me to fix my code, rather than running into a bug in production, or during unit tests.

Keep up the good work Otis

I have to say I'm "shocked" by the comments from "stoop"...

I've been using LLBLGen for what seems like forever and have reported and worked with Frans (Otis) on numerous bugs. The quality of support is LLBLGen's BEST feature and Frans has hit the nail on the head here as all other features in the software become secondary when a problem arises...

By contrast, I have been waiting for a fix from another component vendor now for 6 months. Not only did I have to replicate the bug and provide them with a detailed, step by step, repro case... In the end I had to decompile the component, find the bug myself, tell them where the bug was to be found and how to fix it. Although they have now acknowledged that there is a problem, they still haven't released the FIX.

Frans has always worked "with" his customers to fasttrack the bug fixes which are very often fixed and released the SAME DAY. Where in the world have you seen this before without a dedicated high priced support contract???

Frans your professionalism is to be admired and your support capability is why I recommend LLBLGen to developers all over the world.

Marcus

The entire life of this thread is seven days. Hell, I've waited seven days just to get an acknowledgement of an email I've sent to other vendors.

Het steunen van de twintig buckkerels is het hardst. Laat het niet u hinderen. Ga spel op het strand, besteed zijn geld aan een bier, een medelijden hem, en een drank aan zijn naam.

swallace wrote:

Het steunen van de twintig buckkerels is het hardst. Laat het niet u hinderen. Ga spel op het strand, besteed zijn geld aan een bier, een medelijden hem, en een drank aan zijn naam.

LOL

Bedankt voor de steun, Scott, het bier zal wel smaken denk ik, het strand is alleen wat koud nog

I think this thread should be closed. The issue originally reported is fixed in the latest hotfix for the runtime libraries, released earlier yesterday morning, and I think everyone has said what there is to say.