SetValue exhibits unexpected behavior setting a nullable field of type char(1)

Posts   
 
    
David H
User
Posts: 100
Joined: 31-Dec-2004
# Posted on: 07-Jan-2009 03:43:30   

Setting a nullable string field (verified with a char(1)) to a null or empty string saves a value where a NULL seems to be expected as when setting a nullable integer (see details below).

Is there a better workaround than the one below?

Thanks

David

Version: LLBLGEN 2.6 June 6, 2008.

Example:

dim value as string entity.NullableStringProperty = value

Saves a single character empty value rather than NULL.

Other nullable types do save a NULL in similar assignments. e.g.,

dim value as integer? entity.NullableIntegerProperty = value

Workaround:

Override the property as follows:

Set if not string.isnullorempy(value) then mybase.NullableStringProperty = value endif end Set

Walaa avatar
Walaa
Support Team
Posts: 14995
Joined: 21-Aug-2005
# Posted on: 07-Jan-2009 10:10:15   

Would you please check if the database field corresponding to the NullableStringProperty, does allow null.

And if it does allow null, is that field marked as nullable in the field list of the entity properties in LLBLGen Pro Designer.

If it's not then make sure to set the field to allow null in the database, refresh the catalog, and then regenerate the code and try again.

David H
User
Posts: 100
Joined: 31-Dec-2004
# Posted on: 07-Jan-2009 18:03:34   

That goes without saying -- the field is nullable. I also verified that it is correctly identified as nullable in the LLBLGEN project from the 'Mapped entity fields' tab for the table: The entry under the 'Is nullable' column is True for this field (I wish I could copy that record for your review but the grid record does not allow a copy).

Note also that the workaround I mentioned does result in adding records where this and other nullable fields are saved as NULL.

Walaa avatar
Walaa
Support Team
Posts: 14995
Joined: 21-Aug-2005
# Posted on: 07-Jan-2009 18:08:38   

Setting a nullable string field (verified with a char(1))

What do you mean by verified with a char(1)?

I find this very starnge as we have never faced it before nor reported to us, are you using a any kind of Validation upon this entity? Also which type of database are you using?

David H
User
Posts: 100
Joined: 31-Dec-2004
# Posted on: 07-Jan-2009 18:42:51   

I specifically checked the value that was saved in a field that had a nullable char(1) type before and after implementing the work around. Then I implemented the work around for all other nullable string fields.

I tested the code on my production machine running SQL Express 2008. It then worked OK at the client site under SQL Server 2005. Before the fix we got a foreign key SQL exception.

Note that SetValue works fine for other types but not for the nullable string types.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39909
Joined: 17-Aug-2003
# Posted on: 07-Jan-2009 19:06:43   

What's the runtime library build nr you're using? See: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=7717

(edit), and also: adapter or selfservicing and: be absolutely sure you don't have a default constraint on the field.

Frans Bouma | Lead developer LLBLGen Pro
David H
User
Posts: 100
Joined: 31-Dec-2004
# Posted on: 07-Jan-2009 19:16:09   

LLBLGen Pro. Version: 2.6 Final (June 6th, 2008 ).

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39909
Joined: 17-Aug-2003
# Posted on: 07-Jan-2009 19:19:18   

David wrote:

LLBLGen Pro. Version: 2.6 Final (June 6th, 2008 ).

That's the designer build. I didn't link for the thread in my previous post for nothing simple_smile It's explained there how to obtain the runtime lib build. If it's older than a date in december 2008, please download the latest runtime library from the customer area and try again. Also, please see my edited previous post about more information we need for checking.

Be aware that char field values are padded with spaces by the RDBMS.

Frans Bouma | Lead developer LLBLGen Pro
David H
User
Posts: 100
Joined: 31-Dec-2004
# Posted on: 07-Jan-2009 19:29:47   

Right missed that one - run time: 2.6.8.804

I'll test with the December version sometime tomorrow and let you know.

Thanks for the quick response.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39909
Joined: 17-Aug-2003
# Posted on: 08-Jan-2009 11:50:31   

I can't reproduce it:


[Test]
public void NullValueInCharFieldSaveTest()
{
    AddressEntity address = new AddressEntity();
    address.StreetName = "blaatstraat";
    address.HouseNumber = 13;
    address.City = "Duckstad";
    address.Country = "Disneyland";
    address.TestRunId = Guid.NewGuid();
    address.Zipcode = null;
    using(DataAccessAdapter adapter = new DataAccessAdapter())
    {
        Assert.IsTrue(adapter.SaveEntity(address, true));
    }
    Assert.IsTrue(address.AddressId > 0);
    Assert.IsNull(address.Fields["Zipcode"].CurrentValue);
}


Zipcode is a char(10) field.

You've to check a couple of things: 1) your entity shouldn't be bound to a grid or something, if it is, the bound control likely sets the value to an empty string value 2) if you test this by re-reading the property on the entity after the save, like in my snippet above, if I would do Assert.IsNull(address.Zipcode) after the save it would fail, as the Zipcode property returns "". The value of the field in the db however is NULL. Please check if this is the case for you as well. If so, you can change this in the project properties in llblgen pro: ConvertNulledReferenceTypesToDefaultValues, that setting should be false if you want null values for strings in your .NET code (so reading a string valued property of an entity could result in Nothing instead of ""). Of course code has to be re-generated after this.

Frans Bouma | Lead developer LLBLGen Pro
David H
User
Posts: 100
Joined: 31-Dec-2004
# Posted on: 08-Jan-2009 18:28:55   

Otis,

You hit the nail on the head!

Indeed, the problem stemmed from my reading a value from one table and saving it to another. Because the read returns an empty value for a null, the new value was saved as an empty field.

I hope this is not a total waste of your time - I learned something -- maybe others will too.

Thanks again for the prompt and constructive help.

David

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39909
Joined: 17-Aug-2003
# Posted on: 08-Jan-2009 21:27:16   

Aha simple_smile

Be aware that if you would have given that code snippet in the first post, we would have known right along wink . Anyway, glad it's solved simple_smile

Frans Bouma | Lead developer LLBLGen Pro