Workaround for DBNull defect? - Forum - OpenEdge Development - Progress Community
 Forum

Workaround for DBNull defect?

This question is not answered

Hi there,

does anybody know a workaround for this problem?

DEFINE VARIABLE dataTable AS System.Data.DataTable NO-UNDO.
DEFINE VARIABLE dataColumn AS System.Data.DataColumn NO-UNDO.
DEFINE VARIABLE dataRow AS System.Data.DataRow NO-UNDO.


ASSIGN dataTable = NEW System.Data.DataTable("Whatever")
dataColumn = NEW System.Data.DataColumn("DamnIt", System.Type:GetType("System.Int32"))
dataColumn:AllowDBNull = TRUE
dataColumn:DefaultValue = System.DBNull:Value.

dataTable:Columns:Add(dataColumn).

dataRow = dataTable:NewRow().
dataRow["DamnIt"] = System.DBNull:Value.

All Replies
  • The funny error message says: "Cannot set column 'DamnIt' to be null. Please use DBNull instead."

  • This looks like a bug. If you MESSAGE out System.DBNull:Value, it will show the Unknown value (?).  What is happening is that the right-hand-side (System.DBNull:Value) is being converted to ? when the value is returned from .NET to the AVM.  Then we send it back to .NET to assign it to the column and we translate Unknown back to null, not to DBNull.  I'd have to debug to see what System.DBNull:Value actually is internally.  The question is whether it is something that we can represent inside the AVM other than the Unknown value.  

    I can't think of a work-around at the moment.  I'm kind of surprised this hasn't surfaced before.  I thought we did have use cases using DBNull. Does someone else out there know of a way to code this that works?  

  • This looks like a bug. If you MESSAGE out System.DBNull:Value, it will show the Unknown value (?).  What is happening is that the right-hand-side (System.DBNull:Value) is being converted to ? when the value is returned from .NET to the AVM.  Then we send it back to .NET to assign it to the column and we translate Unknown back to null, not to DBNull.  I'd have to debug to see what System.DBNull:Value actually is internally.  The question is whether it is something that we can represent inside the AVM other than the Unknown value.  

    I can't think of a work-around at the moment.  I'm kind of surprised this hasn't surfaced before.  I thought we did have use cases using DBNull. Does someone else out there know of a way to code this that works?  

  • For new records, a workaround may be to simply not assign the field value at all. I've done this for strings and dates, not sure about integers as I don't think we ever have unknown integer values in my use cases.

    Another possibility, which I have not tested, is to try using System.Convert:DBNull instead of System.DBNull:Value.

  • Using System.Convert:DBNull had the same problem.  But not setting it at all seems to give you want you want.

  • Hi there!

    Thanks for your answers! Not setting the value at all is not an option, because under some circumstances the cell once had a valid integer value and I want to reset it to the unknown value. Currently, the only workaround seems to be to completely delete and recreate the row not setting the cell values at all that should be unknown. Pretty sad...

    (It is definitely a bug. I opened a support case 6 months ago and Progress supposedly recorded this bug as defect PSC00359866. Well... Obviously they didn't.)

  • >> (It is definitely a bug. I opened a support case 6 months ago and Progress supposedly recorded this bug as defect PSC00359866. Well... Obviously they didn't.)

    The bug was submitted to development.  It is currently active and tentatively scheduled for version 12.

     
    Brian Maher
    Principal Engineer, Technical Support
    Progress
    Progress
    14 Oak Park | Bedford, MA 01730 | USA
    phone
    +1 781 280 3075
     
     
    Twitter
    Facebook
    LinkedIn
    Google+
     

  • Thanks Mr. Maher! Where can I see the defects recorded by Progress and when they will be fixed?

  • Customers don’t have direct access to this information.  You can open a support case requesting an update on any bug.
     
     
    Brian Maher
    Principal Engineer, Technical Support
    Progress
    Progress
    14 Oak Park | Bedford, MA 01730 | USA
    phone
    +1 781 280 3075
     
     
    Twitter
    Facebook
    LinkedIn
    Google+
     

  • Awesome.

  • To be more clear, when I said ‘tentatively’ I mean’t that it could be in 12.0 but be forewarned that there is no guarantee that any issue will be fixed in any specific release until it actually is.  Do not rely on what I said to make decisions.
     
    Brian Maher
    Principal Engineer, Technical Support
    Progress
    Progress
    14 Oak Park | Bedford, MA 01730 | USA
    phone
    +1 781 280 3075
     
     
    Twitter
    Facebook
    LinkedIn
    Google+