I have inherited a table with two fields, one decimal, one string. These together represent the primary key. I need both fields on a maintenance form, bound to textboxes.

Display/Edit/Save is working. I cannot get a new record to add.

I get 'Conversion from type 'DBNull' to type 'String' is not valid.' on the line:

Return CType(Me.CurrentRow.Item("ITREPORT"), System.String) in the field properties. I tried to set the defaultValues and the first one sets fine, the second always gives the above error, regardless of the order set. I have PrimaryKeyIsAutoIncremented = False, PrimaryKeyIsUpdateable = True, and even tried out AllowNullsOnNewRow = True. The database fields (DB2) are set to not allow nulls, and have default values set.

I know this could be fixed easily by adding a proper autoincrement key column but I cant, the table is part of a legacy system and the customer is insistant it work as described above, frankly I'm not sure why it isnt. It works fine if the fields are unbound from the textboxes.

I must be missing somethign simple. Which is likely since I havent been coding much lately.

You could try "Return alternate.." in the BO mapper and set the alternate to "String.Empty".

Do you need to be able to store nulls in that column in database? We don't allow any database column to be nullable unless it is absolutely necessary.

Cheers, Peter

NullReferenceException
  Object reference not set to an instance of an object.

Source     : MicroFour StrataFrame AddIns

Stack Trace:
   at MicroFour.StrataFrame.AddIns.DTEprojectsBO.FillProjects(String[] ProjectPaths)
   at MicroFour.StrataFrame.AddIns.PartialClassBuilderCustomizeWizard.ᜀ(ᜏ A_0)
   at MicroFour.StrataFrame.AddIns.PartialClassBuilderCustomizeWizard.ᜀ()
   at MicroFour.StrataFrame.AddIns.PartialClassBuilderCustomizeWizard.OnLoad(EventArgs e)

Hi Keith,

In the BO Mapper, just double click the field you want to modify and on the right side of the Custom Field Properties, set the NULL  Value Option to "Return Alternate on Null" or any other that apply to your case.

I'll admit I am confused why that step was necessary, but I'll save that for another day, unless someone is feeling like enlightening

Keith Chisarik (05/05/2008)

---

I'll admit I am confused why that step was necessary, but I'll save that for another day, unless someone is feeling like enlightening

Well basically that step is there to allow you to handle your specific database Null values, so you can accommodate your SF project to be compatible with any DBNull schema used.  In your particular case you don't have access to modify the database the way you want it, but that will not stop your SF project to keep working.

Just my 0.02