OK, do you have a small sample app that reproduces the problem?  Say, one form, with your one business object?  And just a screen shot of the table in the database so that I can see the structure.  I'm just not seeing anything else that you've done wrong, so I'll probably have to step through it.  Thanks

I am in the process of creating a small sample app of the problem.   I'll keep you posted on how it goes, etc.

Thanks!

Ok, I've created a small app that has the following characteristics

1. Maintains a table that has 3 columns, the first of which is a varchar(10) and is the primary key.

2. The BO for this table has the PK set as required and does not allow null.

3. With this new app, I can edit and save records (of course...#@$%$#@)

4. I am unable to add new records via the form.  The instant I click "New" I get the following exception thrown...

"Unable to cast object of type 'System.DBNull' to type 'System.String'."

Again, it acts like it is trying to add the record to the BO before the user can fill in any data via the form. The only way I've found around this exception is to set the BO to return alternate of String.Empty. 

??????

Ben,

At this point, I think I will throw away the "problem child" and try to create the form again from scratch and see if I get the same problem regarding the edit/save issue.  I would still like to understand the problem I have when trying to add a new record and getting the casting exception.

Thanks!

The reason you're getting the InvalidCastException is because SF does not initialize PK fields when you add a new row.  When you add a new row, all of the other fields are initialized to default values so they won't be DBNull.Value, however, the PK field(s) is(are) left alone.  So, you can either set the ReturnAlternateOnNull option for the pk and return String.Empty (just like you've been doing ), or you can manually set the pk field to String.Empty in the SetDefaultValues() method (in the main code file of the business object).  Either way would work... and then, like you mentioned before, just add either a required field or a custom business rule for the PK, and the user won't be able to enter a blank one into the database (which they would only be able to do once, since the PK has to be unique ).

Ben,

Thanks for the explaination.  That all makes sense now.  I'll let you know how my re-write from scratch goes with the other problem child (edit/save exception).

Regards,

Doug

Trent, Greg, Ben,

I recreated the form, BO, etc from scratch, and all is well with the world.  I have no idea why the first app had the problem with edit/save. Must have been some glitch someplace.  Regardless, I learned a lot and thank each of you for your valued input.

Cheers,

Doug

Glad you got it working. I've had a few problems like that and they are frustrating...and like you, I learned a lot from the posts too!

No problem, glad you got it working