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

The solution will prevent the error, but is not the cause of the error.  You actually should not have to do this.  From what I understand, you are creating a new record.  At this point, the database type has no relavance as all of this is intrinsic to the BO.  So it would appear that when you are adding a record the fields are not being initialized...and/or you are referencing this field either through a manual binding, event, or some other code before it gets initialized.

By default, a BO has the AllowNullValuesONnewRow set to false, which forces all rows to be initialized with a default value when a new row is created.  So the NULL is not coming from there...it is happening in the Get of the strong-typed property which means that something is trying to call a GetValue before it is initialized.

You might check your mappings or place a breakpoint in the Get of the property to see what is pulling the value.  You have a "bandaid" on it so to speak and it would probably be a good idea to find the source of the issue.

If not, what might be causing this, I need my bandaid back as it is not clear to me what the underlying problem is.

2) Field_ITREPORT_Descriptor is making the call to the get  for Public Property [ITREPORT]() As System.String

Well, it is possible that your SF database is not up to date, but the issue here is that you created the custom code in Database 1 and are now wanting to work on Database 2.  So that code that was in DB1 is not going to be there.  If you set your data source base to DB1, do you get your stuff back?

That is the first thing I would make sure of.  Then...well...we can try to come up with the best solution for working like this.

The new database will be the master from now on, I have VPN access to it.