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.
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
|
||||
|
14 Oak Park | Bedford, MA 01730 | USA
|
||||
|
||||
|
Thanks Mr. Maher! Where can I see the defects recorded by Progress and when they will be fixed?
|
|
||||
|
Brian Maher
|
||||
|
Principal Engineer, Technical Support
|
||||
 |
||||
|
Progress
|
||||
|
14 Oak Park | Bedford, MA 01730 | USA
|
||||
|
||||
|
Awesome.
|
|
||||
|
Brian Maher
|
||||
|
Principal Engineer, Technical Support
|
||||
 |
||||
|
Progress
|
||||
|
14 Oak Park | Bedford, MA 01730 | USA
|
||||
|
||||
|
