webservice and typed datasets

[Mike]

Hi,

I'm delevloping a webservice that returns typed datasets with visual
studio 2005. The problem is, that the typed data set in the client app
is not the same as in the webservice. If I change the property
'NullValue' of the row to (empty) the dataset on the client does still
throw an exception. I added a column to see if the project updates the
reference.cs - and it does!

This is the generated code from the original dataset:
[System.Diagnost ics.DebuggerNon UserCodeAttribu te()]
public string Firstname {
get {
if (this.IsFirstna meNull()) {
return string.Empty;
}
else {
return
((string)(this[this.tableAuthU sers.FirstnameC olumn]));
}
}
set {
this[this.tableAuthU sers.FirstnameC olumn] = value;
}
}

And this the code in the reference.cs:
[System.Diagnost ics.DebuggerNon UserCodeAttribu te()]
public string Firstname {
get {
try {
return
((string)(this[this.tableAuthU sers.FirstnameC olumn]));
}
catch (System.Invalid CastException e) {
throw new
System.Data.Str ongTypingExcept ion("Der Wert für Spalte Firstname in
Tabelle AuthUsers ist DBNull.", e);
}
}
set {
this[this.tableAuthU sers.FirstnameC olumn] = value;
}
}
Is this a bug or is it expected behavior? Can anyone tell me how to
work around?
Thanks in advance.

Mike

[Dave Sexton]

Hi Mike,

The setting for how a Typed DataSet will handle string DataColumns with a
value of DBNull is only used when the DataSet is first created by the
MSDataSetGenera tor. The setting is not present in the schema for the
DataSet (it's only a setting that the generator understands).

When the DataSet is stubbed out on the client the null-handling setting for
string DataColumns isn't retained since it's not part of the DataSet's
schema.

I don't think this is a bug, since standardized Web Services shouldn't have
to make an exception to process DataSets differently because of a missing
feature in the xsd standards.

Anyone consuming the DataSet should first check the IsFirstnameNull method
before attempting to read the Firstname property. This is the usual way of
coding against a Type DataSet so it shouldn't be unintuitive for developers
that are using your Web Service.

--
Dave Sexton

"Mike" <m.********@sls ervices.dewrote in message
news:11******** **************@ 73g2000cwn.goog legroups.com...
Hi,

I'm delevloping a webservice that returns typed datasets with visual
studio 2005. The problem is, that the typed data set in the client app
is not the same as in the webservice. If I change the property
'NullValue' of the row to (empty) the dataset on the client does still
throw an exception. I added a column to see if the project updates the
reference.cs - and it does!

This is the generated code from the original dataset:
[System.Diagnost ics.DebuggerNon UserCodeAttribu te()]
public string Firstname {
get {
if (this.IsFirstna meNull()) {
return string.Empty;
}
else {
return
((string)(this[this.tableAuthU sers.FirstnameC olumn]));
}
}
set {
this[this.tableAuthU sers.FirstnameC olumn] = value;
}
}

And this the code in the reference.cs:
[System.Diagnost ics.DebuggerNon UserCodeAttribu te()]
public string Firstname {
get {
try {
return
((string)(this[this.tableAuthU sers.FirstnameC olumn]));
}
catch (System.Invalid CastException e) {
throw new
System.Data.Str ongTypingExcept ion("Der Wert für Spalte Firstname in
Tabelle AuthUsers ist DBNull.", e);
}
}
set {
this[this.tableAuthU sers.FirstnameC olumn] = value;
}
}
Is this a bug or is it expected behavior? Can anyone tell me how to
work around?
Thanks in advance.

Mike

[Dave Sexton]

Hi Mike,

I don't think this is a bug, since standardized Web Services shouldn't
have to make an exception to process DataSets differently because of a
missing feature in the xsd standards.

On second thought, this does appear to be a bug.

I tested it myself and the xsd generated by the Web Service for a DataSet
does include "msdata" namespace attributes. So, I don't see why the
"msprop" namespace isn't included as well. msprop:nullValu e="_empty" is the
setting to which you referred in your OP, so it could have been added to the
xsd for the Typed DataSet just as easily as the msdata attributes.

--
Dave Sexton

"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:Oh******** ******@TK2MSFTN GP02.phx.gbl...

Hi Mike,

The setting for how a Typed DataSet will handle string DataColumns with a
value of DBNull is only used when the DataSet is first created by the
MSDataSetGenera tor. The setting is not present in the schema for the
DataSet (it's only a setting that the generator understands).

When the DataSet is stubbed out on the client the null-handling setting
for string DataColumns isn't retained since it's not part of the DataSet's
schema.

I don't think this is a bug, since standardized Web Services shouldn't
have to make an exception to process DataSets differently because of a
missing feature in the xsd standards.

Anyone consuming the DataSet should first check the IsFirstnameNull method
before attempting to read the Firstname property. This is the usual way
of coding against a Type DataSet so it shouldn't be unintuitive for
developers that are using your Web Service.

--
Dave Sexton

"Mike" <m.********@sls ervices.dewrote in message
news:11******** **************@ 73g2000cwn.goog legroups.com...
Hi,

I'm delevloping a webservice that returns typed datasets with visual
studio 2005. The problem is, that the typed data set in the client app
is not the same as in the webservice. If I change the property
'NullValue' of the row to (empty) the dataset on the client does still
throw an exception. I added a column to see if the project updates the
reference.cs - and it does!

This is the generated code from the original dataset:
[System.Diagnost ics.DebuggerNon UserCodeAttribu te()]
public string Firstname {
get {
if (this.IsFirstna meNull()) {
return string.Empty;
}
else {
return
((string)(this[this.tableAuthU sers.FirstnameC olumn]));
}
}
set {
this[this.tableAuthU sers.FirstnameC olumn] = value;
}
}

And this the code in the reference.cs:
[System.Diagnost ics.DebuggerNon UserCodeAttribu te()]
public string Firstname {
get {
try {
return
((string)(this[this.tableAuthU sers.FirstnameC olumn]));
}
catch (System.Invalid CastException e) {
throw new
System.Data.Str ongTypingExcept ion("Der Wert für Spalte Firstname in
Tabelle AuthUsers ist DBNull.", e);
}
}
set {
this[this.tableAuthU sers.FirstnameC olumn] = value;
}
}
Is this a bug or is it expected behavior? Can anyone tell me how to
work around?
Thanks in advance.

Mike

[Mike]

Hi Dave,

Thanks for the replay. I guess this is a bug, too. The problem is that
it is not possible to use standard data binding with the object data
source in web forms. The only thing that I figured out to work around
is to merge the dataset into a new one. But this is not very handy and
you loose all benefits of the typed dataset.
It's very hard for me to believe, that I'm the first one who tries to
use typed datasets, web services and data binding. These are the new
Microsoft standards for n-tier applications, no?

Mike