Table Adapter with null on numerical data

[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.GeneratedFi eld ?? default

or to check row.GeneratedFi eld.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.GeneratedFi eld; ... } 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

[Michel Walsh]

Hi,
found (remembered) an alternative to coalesce ( ?? ), at least. Indeed,
instead of:
... row.GeneratedFi eld ?? defaultInThisCi rcumstance ... ; // pseudo
code

can 'simply' use:

... (row.IsGenerate dFieldNull ? defaultInThisCi rcumstance :
row.GeneratedFi eld) ...
without having the try{} block performance penalty, since IsXxxxNull is also
automatically generated, for each Xxxx field. And I don't have to build
special "view" either to convert my "nullable" fields as strings. It is not
"as elegant as" having a nullable data type, but can live with it, for sure.

Vanderghast, Access MVP

"Michel Walsh" <vanderghast@Vi rusAreFunnierTh anSpam> wrote in message
news:uS******** ******@TK2MSFTN GP02.phx.gbl...

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.GeneratedFi eld ?? default

or to check row.GeneratedFi eld.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.GeneratedFi eld; ... } 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