I have a windows app, written in VB.NET, using VS.NET 2003, which, in part accesses a SQL Server 7.0 database, using some datasets.
Go along fine, load data, display data, change data, process data, delete data, . . . great.
Then "out of the blue" start getting DBNull error message. Exact text:
"An unhandled exception of the type 'System.Data.StrongTypingException' occurred in MyApp.exe
Additional information: Cannot get value becuase it is DBNull"
A. Yea so? For the column/field to which it breaks upon, the DB allows Null values . . . so? it is Null?, it is perfectly OK. Why throw an error?
B. Yes, dataSet.EnforceConstraints = False
I used dataset wizard to create the dataset, xml (which btw has <xs:element name="fieldname" type="xs:int" minOccurs="0" />)
I really do not understand why it is throwing the error in the first place, as the database allows a null for the column (and the column is not part of the table(s) key).
What is really driving me batty is that it worked before, with same data (that is some null values in the column now causing trouble). It is just that all of the sudden it starts throwing this stupid error.
Is building/rebuilding form/solution/project doing something behind the scenes? Is it somehow re-running/running "Run Custom Tool" on the dataset? Is it the bindgs getting thrown off.
As a lot of the underlying code is system/VS generated I am not sure as to where or what to begin hunting down cause of the problem (i.e. why it works then all of the sudden stops) or why/where to fix code so it does not give the stupid DBNull error.
Any help appreciated.
btw am getting the error in mydataset.vb code at/when it Gets:
Public Property FieldName As Integer
Catch e As InvalidCastException
Throw New StrongTypingException("Cannot get value because it is DBNull.", e)
Me(Me.tableMaterialColor.FrequencyColumn) = value
I understadn the above code. Yes, for some rows it is null. But, as I said above, it did not throw the error before and poof it is throwing the error.
There are other columns set up exactly the same (except type might be different, e.g. string, or decimal, etc.) and they do not throw the error, even though some rows/values are also DBNull.
I could, and did go in, add code and catch whether it is Null before it throws the error/skip the error, but still leaves unanswered why it started doing this in the first place . . . does one have to go in a periodically/randomly add code, if/when VB/VS/SQL decides it just feels like it? :)