M
Michel Walsh
Hi,
Just get my hand on "Data Binding Windows Forms 2.0 Programming Smart
Client Data Applications with .Net", by Brian Noyes (Addison Wesley), with a
nice illustration on using generated code with strongly type dataset, in the
chapter 2.
BUT, I have a problem with Null, when on a not-string data. With String
Data, the Strong Type Data-Set generated code, by VS2005, allows to pass
Null as Empty string, but for non string data, the only option is to throw
an exception when a null is meet (inside the generated code).
Furthermore, it would have been nice if the framework would have allowed the
use of Nullable<T>, but it does not, quite UNFORTUNATELY. Indeed, a
"working" alternative is to modify, by hand, the generate code, changing the
int into int?, as example, and removing the throw new Exception, with return
(int?) null; and voila, just need to coalesce in my code:
row.GeneratedField ?? default
or to check row.GeneratedField.HasValue, but the problem with that
solution, is that your changes are destroyed each time the code is
regenerated. Not really good.
Handling with a try block also works, but doing so each time you access the
field:
try{ ... row.GeneratedField; ... } catch { ... }
that just kill performance. Have to forget that solution.
Handling the conversion in the SQL Server, rather than in .Net code, is also
doable, but that increases the number of views on the server (to satisfy
particular needs of particular code implementation), couple the code with
the view (without null), and add to the server burden, where the thick
client would have otherwise do the job very well... if it can handle the
null, that is.
Someone has some OTHER suggestion on how I can handle the null in the
strongly type code generated table adapters?
thanks,
Vanderghast, Access MVP
Just get my hand on "Data Binding Windows Forms 2.0 Programming Smart
Client Data Applications with .Net", by Brian Noyes (Addison Wesley), with a
nice illustration on using generated code with strongly type dataset, in the
chapter 2.
BUT, I have a problem with Null, when on a not-string data. With String
Data, the Strong Type Data-Set generated code, by VS2005, allows to pass
Null as Empty string, but for non string data, the only option is to throw
an exception when a null is meet (inside the generated code).
Furthermore, it would have been nice if the framework would have allowed the
use of Nullable<T>, but it does not, quite UNFORTUNATELY. Indeed, a
"working" alternative is to modify, by hand, the generate code, changing the
int into int?, as example, and removing the throw new Exception, with return
(int?) null; and voila, just need to coalesce in my code:
row.GeneratedField ?? default
or to check row.GeneratedField.HasValue, but the problem with that
solution, is that your changes are destroyed each time the code is
regenerated. Not really good.
Handling with a try block also works, but doing so each time you access the
field:
try{ ... row.GeneratedField; ... } catch { ... }
that just kill performance. Have to forget that solution.
Handling the conversion in the SQL Server, rather than in .Net code, is also
doable, but that increases the number of views on the server (to satisfy
particular needs of particular code implementation), couple the code with
the view (without null), and add to the server burden, where the thick
client would have otherwise do the job very well... if it can handle the
null, that is.
Someone has some OTHER suggestion on how I can handle the null in the
strongly type code generated table adapters?
thanks,
Vanderghast, Access MVP