I have (well, had ) an issue with how Gen Pro (2.5) entities handle fields that aren't nullable in a database field, using data types that are not nullable. In my particular case, I have a field of data type int, which of course in the entity defaults to 0.
I have a grid in which I am entering data. To give it context, I am entering sections of depths of a well bore, to describe properties pertaining to those specific depths. The first depth starts at 0, and goes down X feet. Therefore, I actually want the first StartDepth, which is an integer, to be 0. It defaults to this value, so I leave it alone and enter the EndDepth and go on to the next record, etc.
Problem is, when I go to save the data, I get an SQL error that tells me that the StartDepth field cannot be null. Obviously, the entity is carrying the DBValue as null. If I change the StartDepth field to anything other than 0, then back to 0, of course, it works fine.
Ok, so I got to this point and realized that I didn't have the field defaulted to anything in the database. When I went to the table and defaulted the field to 0, Gen Pro behaves well in this respect because the insert query does not try to insert a null into the field, instead allowing the database to insert the default value in the field. So when I save, I don't have the problem mentioned.
So then this raises another possible related issue. Gen Pro does not look at the Default property of the field in the database, or allow the user in the designer to set a default value for a field (that I'm aware of). It uses the default value for the given property's data type. So, for example, if I were to solve my problem above by putting in a default value, as long as it is 0, matching an int's default value in GenPro, I'm ok. But if I were to put, say, 1 (or 5, etc), and allow 0 as a valid value (in other words, not creating a validation problem with 0), then the field would default to Gen Pro's 0 for an int field, display that to the user, who would not change it, and then when the user saves it, the field would revert to the default value in the database.
The only real problem I have with this is that the user may not see this change in value if the form that displays the data is no longer open when the data is saved (or if, as is often the case, the user is not very observant). If the form is open, the field visually reverts to the default value that is in the database after the save and the user can notice that and change it back, although possibly with some aggravation.
Now, this is not necessarily a huge issue by any means. I don't know that I would ever put some default value on an int, for example, other than 0 (but I'm sure it's not unreasonable to think it may be needed), but since I'd started writing about an issue I thought I had, then realized how to correct it, that I'd go ahead and post on this part of it as well.
Is it possible to grab the default value from the database and use it instead of the Gen Pro default type value? Is there a reason not to? Again, just curious at this point, not a big deal, but something that might keep someone from having an unexpected issue somewhere down the line.