Setting float column (System.Double) to null

Posts   
 
    
Chester
Support Team
Posts: 223
Joined: 15-Jul-2005
# Posted on: 05-May-2006 16:51:22   

I'm using version 1.0.2005.1 of LLBLGen, on .NET Framework 1.1, with MS SQL 2000 as the database. We're using the SelfServicing, two-class scenario template in VB.NET.

I have a database table with several nullable float columns, and (of course) a corresponding entity with corresponding properties as System.Double.

How do I set these property values to null?

Here's my current code:


myEntity.SetNewFieldValue(name, value)

name is the name of the property, and value is an object. This is VB.NET, so I've tried using both "Nothing" and "DBNull.Value". If I use "Nothing", the column still is set to 0.0. I can't use DBNull.Value because this blows up with the following Exception:

"The value is of type 'System.DBNull' while the field is of type 'System.Double'"

Can someone help me work around this?

bclubb
User
Posts: 934
Joined: 12-Feb-2004
# Posted on: 06-May-2006 00:37:29   

The value will still be 0.0 in .NET because a double can't be nothing, but if you save the value to the database it should null. You can check that the value is null by using this method

TestCurrentFieldValueForNull

and not checking the value of the double property.

Chester
Support Team
Posts: 223
Joined: 15-Jul-2005
# Posted on: 08-May-2006 21:51:24   

bclubb wrote:

The value will still be 0.0 in .NET because a double can't be nothing, but if you save the value to the database it should null. You can check that the value is null by using this method

TestCurrentFieldValueForNull

and not checking the value of the double property.

Nevermind! I realized that the code I quoted in my original post was only half of what was going on. I am always saving a new instance of the entity even when an update is made so as to track history of the object. This code is what was failing. Thanks anyway!

Chester
Support Team
Posts: 223
Joined: 15-Jul-2005
# Posted on: 08-May-2006 21:52:16   

bclubb wrote:

The value will still be 0.0 in .NET because a double can't be nothing, but if you save the value to the database it should null. You can check that the value is null by using this method

TestCurrentFieldValueForNull

and not checking the value of the double property.

Nevermind! I realized that the code I quoted in my original post was only half of what was going on. I am always saving a new instance of the entity even when an update is made so as to track history of the object. This code is what was failing. Thanks anyway!

Chester
Support Team
Posts: 223
Joined: 15-Jul-2005
# Posted on: 08-May-2006 21:54:16   

bclubb wrote:

The value will still be 0.0 in .NET because a double can't be nothing, but if you save the value to the database it should null. You can check that the value is null by using this method

TestCurrentFieldValueForNull

and not checking the value of the double property.

Nevermind! I realized that the code I quoted in my original post was only half of what was going on. I am always saving a new instance of the entity even when an update is made so as to track history of the object. This code is what was failing. Thanks anyway!

Chester
Support Team
Posts: 223
Joined: 15-Jul-2005
# Posted on: 08-May-2006 21:56:16   

bclubb wrote:

The value will still be 0.0 in .NET because a double can't be nothing, but if you save the value to the database it should null. You can check that the value is null by using this method

TestCurrentFieldValueForNull

and not checking the value of the double property.

Nevermind! I realized that the code I quoted in my original post was only half of what was going on. I am always saving a new instance of the entity even when an update is made so as to track history of the object. This code is what was failing. Thanks anyway!

Chester
Support Team
Posts: 223
Joined: 15-Jul-2005
# Posted on: 08-May-2006 21:58:16   

bclubb wrote:

The value will still be 0.0 in .NET because a double can't be nothing, but if you save the value to the database it should null. You can check that the value is null by using this method

TestCurrentFieldValueForNull

and not checking the value of the double property.

Nevermind! I realized that the code I quoted in my original post was only half of what was going on. I am always saving a new instance of the entity even when an update is made so as to track history of the object. This code is what was failing. Thanks anyway!

Chester
Support Team
Posts: 223
Joined: 15-Jul-2005
# Posted on: 08-May-2006 22:00:16   

bclubb wrote:

The value will still be 0.0 in .NET because a double can't be nothing, but if you save the value to the database it should null. You can check that the value is null by using this method

TestCurrentFieldValueForNull

and not checking the value of the double property.

Nevermind! I realized that the code I quoted in my original post was only half of what was going on. I am always saving a new instance of the entity even when an update is made so as to track history of the object. This code is what was failing. Thanks anyway!

Chester
Support Team
Posts: 223
Joined: 15-Jul-2005
# Posted on: 08-May-2006 22:02:16   

bclubb wrote:

The value will still be 0.0 in .NET because a double can't be nothing, but if you save the value to the database it should null. You can check that the value is null by using this method

TestCurrentFieldValueForNull

and not checking the value of the double property.

Nevermind! I realized that the code I quoted in my original post was only half of what was going on. I am always saving a new instance of the entity even when an update is made so as to track history of the object. This code is what was failing. Thanks anyway!

Chester
Support Team
Posts: 223
Joined: 15-Jul-2005
# Posted on: 08-May-2006 22:04:16   

bclubb wrote:

The value will still be 0.0 in .NET because a double can't be nothing, but if you save the value to the database it should null. You can check that the value is null by using this method

TestCurrentFieldValueForNull

and not checking the value of the double property.

Nevermind! I realized that the code I quoted in my original post was only half of what was going on. I am always saving a new instance of the entity even when an update is made so as to track history of the object. This code is what was failing. Thanks anyway!