473,834 Members | 1,801 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Returning Dataset or Datatable via Web Service

I'm a bit puzzled by the current recommendation not to send Datasets or
Datatables between application tiers.

http://support.microsoft.com/kb/306134

http://msdn2.microsoft.com/en-us/library/ms996381.aspx

Formerly, with classic Microsoft DNA architecture, the ADO Recordset was a
primary transport medium, recommended for transmitting data between
application tiers. In fact, there are whole books written on the subject.

So, I'm a bit puzzled why this hasn't been carried forward into ADO.NET. In
any case, what then is the recommended alternative? Manually serialize and
pass the XML? So why can't this happen automatically for us, just as was the
case with classic ADO recordsets?

Thanks for your advice?

- Joseph Geretz -
Feb 23 '07 #1
15 13520
Joseph Geretz,

The error message mentioned in the microsoft site is for a different cause.
You can pass DataSet / DataTable back & forth between web service.
The DataSet / DataTable serialization is supported in ADO.NET 2.0.
I'm not finding any restriction to use theam

--
Thanks & Regards,
Mark Nelson
"Joseph Geretz" wrote:
I'm a bit puzzled by the current recommendation not to send Datasets or
Datatables between application tiers.

http://support.microsoft.com/kb/306134

http://msdn2.microsoft.com/en-us/library/ms996381.aspx

Formerly, with classic Microsoft DNA architecture, the ADO Recordset was a
primary transport medium, recommended for transmitting data between
application tiers. In fact, there are whole books written on the subject.

So, I'm a bit puzzled why this hasn't been carried forward into ADO.NET. In
any case, what then is the recommended alternative? Manually serialize and
pass the XML? So why can't this happen automatically for us, just as was the
case with classic ADO recordsets?

Thanks for your advice?

- Joseph Geretz -
Feb 23 '07 #2
Hi Mark,

I didn't say it wouldn't work. It does work. But it's not recommended:

http://msdn2.microsoft.com/en-us/lib...emotes_topic11

Avoid passing DataSets between services

In our tests, choosing the way the services and callers exchange data-as
DataSets or serialized structures-resulted in a much bigger performance
impact than choosing any particular distributed systems technology over
another.

From a performance perspective, we strongly urge you to limit your use of
DataSets as a data transfer mechanism to the parts of your application where
they are truly needed and that you opt for [Serializable] structures
wherever possible.

ADO.NET DataSets provide a great way to retrieve, manipulate, sort, and
shape data, store it locally for offline use, and synchronize changes back
into a central database. If this is a requirement of your application, then
of course, it's a valid choice to make. In the .NET Framework 1.x, DataSet
values are always serialized to XML (even if you state that you want them
serialized as binary or use them with ES or Remoting), and they also contain
the XSD describing the data. This, of course, impacts performance.

What's more, remember that DataSets are a .NET-specific technology and will
significantly limit your interoperabilit y as other platforms won't
necessarily be able to serialize and parse data containing serialized
DataSets.

You can gain considerable performance improvements by instead exchanging
serialized data structures. The built-in runtime formatting and XML
serialization framework makes it easy, as shown in the tests above.

- Joe Geretz -

"Mark Nelson" <Ma********@dis cussions.micros oft.comwrote in message
news:4F******** *************** ***********@mic rosoft.com...
Joseph Geretz,

The error message mentioned in the microsoft site is for a different
cause.
You can pass DataSet / DataTable back & forth between web service.
The DataSet / DataTable serialization is supported in ADO.NET 2.0.
I'm not finding any restriction to use theam

--
Thanks & Regards,
Mark Nelson
"Joseph Geretz" wrote:
>I'm a bit puzzled by the current recommendation not to send Datasets or
Datatables between application tiers.

http://support.microsoft.com/kb/306134

http://msdn2.microsoft.com/en-us/library/ms996381.aspx

Formerly, with classic Microsoft DNA architecture, the ADO Recordset was
a
primary transport medium, recommended for transmitting data between
application tiers. In fact, there are whole books written on the subject.

So, I'm a bit puzzled why this hasn't been carried forward into ADO.NET.
In
any case, what then is the recommended alternative? Manually serialize
and
pass the XML? So why can't this happen automatically for us, just as was
the
case with classic ADO recordsets?

Thanks for your advice?

- Joseph Geretz -

Feb 23 '07 #3
"Joseph Geretz" <jg*****@nospam .comwrote in message
news:OY******** ******@TK2MSFTN GP04.phx.gbl...
I'm a bit puzzled by the current recommendation not to send Datasets or
Datatables between application tiers.

Joseph, have you decided that your web service will only be consumed by .NET
clients, ever?

If you want to be able to take advantage of the cross-platform benefits
offered by XML Web Services, then you should stop thinking about exposing
classes and DataSets and DataTables. Instead, think about exposing XML.

John
Feb 23 '07 #4
Isn't everything fundamentally serialized as XML anyway?

So the recommendation is basically to get a DataSet/Table on the server,
manually serialize to XML, receive it on the client, and then do whatever
you want with it, including de-persisting the XML into a DataSet/Table if
the client is so inclined?

But my fundamental question still exists: Regardless of how I define the
data, the response is going to come back as XML won't it? So why would a non
..NET client have more difficulty dealing with the DataSet/Table XML as
opposed to my own explicitly defined XML?

- Joseph Geretz -

"John Saunders" <john.saunder s at trizetto.comwro te in message
news:uX******** ******@TK2MSFTN GP04.phx.gbl...
"Joseph Geretz" <jg*****@nospam .comwrote in message
news:OY******** ******@TK2MSFTN GP04.phx.gbl...
>I'm a bit puzzled by the current recommendation not to send Datasets or
Datatables between application tiers.


Joseph, have you decided that your web service will only be consumed by
.NET clients, ever?

If you want to be able to take advantage of the cross-platform benefits
offered by XML Web Services, then you should stop thinking about exposing
classes and DataSets and DataTables. Instead, think about exposing XML.

John


Feb 23 '07 #5
"Joseph Geretz" <jg*****@nospam .comwrote in message
news:uQ******** ******@TK2MSFTN GP06.phx.gbl...
Isn't everything fundamentally serialized as XML anyway?

So the recommendation is basically to get a DataSet/Table on the server,
manually serialize to XML, receive it on the client, and then do whatever
you want with it, including de-persisting the XML into a DataSet/Table if
the client is so inclined?

But my fundamental question still exists: Regardless of how I define the
data, the response is going to come back as XML won't it? So why would a
non .NET client have more difficulty dealing with the DataSet/Table XML as
opposed to my own explicitly defined XML?
Joseph,

This will become a lot clearer once you've had more experience with XML. We
all go through the stage you're in - thinking about XML as being just a text
format. It's grown way beyond that, and a lot of its power comes from this
growth.

One thing that's newly-enabled by XML is that the client of your web service
may be running on a platform you've never heard of. Because both sides are
adhering to standards, you won't actually need to know what kind of client
is consuming your service. This is possible, in part, because the metadata
of your service is described in WSDL and XML Schema, both of which are XML
languages.

Now, one aspect of the fact that you can't know who your client is, is the
fact that you can't know that they will be able to process a DataSet in any
sensible way. So, don't send them a DataSet.

Perhaps more importantly, a DataSet is a server-side, implementation-level
object. The communication between the client and server should be in terms
of the business-level concepts, not in terms of how the server happened to
implement the service.

I don't know of many businesses for which "DataSet" is a business-level
concept.

You should ideally start with the business-level concept, manually create an
XML Schema to describe it, manually create a WSDL file which will describe
the possible interactions with the service in terms of the schema, and only
_then_ go implement a service which may implement these concepts and
operations in terms of DataSets.

That way, you are in control of the contract - the promises made to your
client by your WSDL file.

John
Feb 23 '07 #6
Hi John,
You should ideally start with the business-level concept, manually create
an XML Schema to describe it, manually create a WSDL file which will
describe the possible interactions with the service in terms of the
schema, and only _then_ go implement a service which may implement these
concepts and operations in terms of DataSets.
I hear what you are saying, but I'm wondering why you're saying it in a
dotnet.framewor k.webservices forum. The activities you describe, that is the
hand tuning of the XML schema and the WSDL file are specifically those
activities which are *not* necessary for .NET developers. We use a more RAD
approach, basically relying on the IDE to perform this for us behind the
scenes.

The application I am currently devleoping would have two target audiences.

1. Our own client application. Our developed solution would be implemented
end-to-end using Microsoft .NET technologies using the aforementioned RAD
approach.

2. Other vendors in our application market space who might want to integrate
with our application. Web Services would facilitate this type of
integration. Certain vendors might or might not be on the .NET platform
themselves. For those who are, terrific for them, they'll be able to consume
our web services quite naturally with the convenience of being able to
access tabular data in a very convenient format. Those who aren't should
still be able to consume our Web Services, however they'll have to manually
parse through tabular data themselves without the convenience of the
DataTable/DataSet structure since their environments won't provide the
convenience of an object representation of the DataTable/Set XML.
I don't know of many businesses for which "DataSet" is a business-level
concept.
The DataSet/Table isn't a business level concept, however a large amount of
business level data can be represented quite conveniently in DataSet/Table
format. With focus on devleopment convenience (RAD) for our own application
developers, I need a more compelling reason to eschew DataSet/Tables than
simply the fact that it will disadvantage other non .NET consumers of our
Web Service. If it will make it impossible for them to consume our Web
Services, that would be a different matter. But I'm not hearing that it
would be impossible for them, just marginally more inconvenient.

Am I missing anything?

Thanks,

- Joseph Geretz -

"John Saunders" <john.saunder s at trizetto.comwro te in message
news:%2******** ********@TK2MSF TNGP02.phx.gbl. ..
"Joseph Geretz" <jg*****@nospam .comwrote in message
news:uQ******** ******@TK2MSFTN GP06.phx.gbl...
>Isn't everything fundamentally serialized as XML anyway?

So the recommendation is basically to get a DataSet/Table on the server,
manually serialize to XML, receive it on the client, and then do whatever
you want with it, including de-persisting the XML into a DataSet/Table if
the client is so inclined?

But my fundamental question still exists: Regardless of how I define the
data, the response is going to come back as XML won't it? So why would a
non .NET client have more difficulty dealing with the DataSet/Table XML
as opposed to my own explicitly defined XML?

Joseph,

This will become a lot clearer once you've had more experience with XML.
We all go through the stage you're in - thinking about XML as being just a
text format. It's grown way beyond that, and a lot of its power comes from
this growth.

One thing that's newly-enabled by XML is that the client of your web
service may be running on a platform you've never heard of. Because both
sides are adhering to standards, you won't actually need to know what kind
of client is consuming your service. This is possible, in part, because
the metadata of your service is described in WSDL and XML Schema, both of
which are XML languages.

Now, one aspect of the fact that you can't know who your client is, is the
fact that you can't know that they will be able to process a DataSet in
any sensible way. So, don't send them a DataSet.

Perhaps more importantly, a DataSet is a server-side, implementation-level
object. The communication between the client and server should be in terms
of the business-level concepts, not in terms of how the server happened to
implement the service.

I don't know of many businesses for which "DataSet" is a business-level
concept.

You should ideally start with the business-level concept, manually create
an XML Schema to describe it, manually create a WSDL file which will
describe the possible interactions with the service in terms of the
schema, and only _then_ go implement a service which may implement these
concepts and operations in terms of DataSets.

That way, you are in control of the contract - the promises made to your
client by your WSDL file.

John


Feb 23 '07 #7
"Joseph Geretz" <jg*****@nospam .comwrote in message
news:uX******** ******@TK2MSFTN GP05.phx.gbl...
Hi John,
>You should ideally start with the business-level concept, manually create
an XML Schema to describe it, manually create a WSDL file which will
describe the possible interactions with the service in terms of the
schema, and only _then_ go implement a service which may implement these
concepts and operations in terms of DataSets.

I hear what you are saying, but I'm wondering why you're saying it in a
dotnet.framewor k.webservices forum. The activities you describe, that is
the hand tuning of the XML schema and the WSDL file are specifically those
activities which are *not* necessary for .NET developers. We use a more
RAD approach, basically relying on the IDE to perform this for us behind
the scenes.

Sorry, you're mistaken. .NET does not equate to RAD, esepecially not for web
services. I practiced what I preached on one web service and am about to do
so again on at least one more. This is called contract-first development.

The application I am currently devleoping would have two target audiences.

1. Our own client application. Our developed solution would be implemented
end-to-end using Microsoft .NET technologies using the aforementioned RAD
approach.
It's not a problem if you want to tie yourself to .NET. That works very
well, until the point when you decide you need to work with something that's
not .NET.
2. Other vendors in our application market space who might want to
integrate with our application. Web Services would facilitate this type of
integration. Certain vendors might or might not be on the .NET platform
themselves. For those who are, terrific for them, they'll be able to
consume our web services quite naturally with the convenience of being
able to access tabular data in a very convenient format. Those who aren't
should still be able to consume our Web Services, however they'll have to
manually parse through tabular data themselves without the convenience of
the DataTable/DataSet structure since their environments won't provide the
convenience of an object representation of the DataTable/Set XML.

What's wrong with defining your tabular data with a schema, without relying
on a DataSet?

And, you may find some market resistance if you are asking partners to parse
through your XML.
>I don't know of many businesses for which "DataSet" is a business-level
concept.

The DataSet/Table isn't a business level concept, however a large amount
of business level data can be represented quite conveniently in
DataSet/Table format. With focus on devleopment convenience (RAD) for our
own application developers, I need a more compelling reason to eschew
DataSet/Tables than simply the fact that it will disadvantage other non
.NET consumers of our Web Service. If it will make it impossible for them
to consume our Web Services, that would be a different matter. But I'm not
hearing that it would be impossible for them, just marginally more
inconvenient.

Am I missing anything?
Have you tried strongly-typed datasets? They're nice and RAD, but they at
least define the data via XML Schema. You get to benefit from RAD, your
customers benefit from a strong schema.

John
BTW, I presume you realize that you need to be careful when changing the
structure of the data you're returning? Once you've published the WSDL, you
shouldn't really be changing the structure of the returned data, at least
not without a versioning mechanism. Again, you may get away with things like
adding columns with some clients, but maybe not with others.
Feb 23 '07 #8
Hi John,
Sorry, you're mistaken. .NET does not equate to RAD, esepecially not for
web services.
I (and some other developers on the team here) don't quite understand what
you are saying. When using Visual Studio 2005 for Web Service application
development, the IDE takes care of all the wire-up necessary in order to
connect the client with the Web Service. This includes creating the WSDL on
the server and creating the proxy class for the client which consumes the
WSDL and presents a strongly typed interface to the client. Seems pretty RAD
to us.
What's wrong with defining your tabular data with a schema, without
relying on a DataSet?
There's nothing wrong with it, in general. However consider the context in
particular. The data is retrieved from the database in DataTable format. At
the (our) UI it's going to be bound to a data-bound widget (very convenient,
for us at least) in DataTable format. Given that this is the case, I'm going
to need a compelling reason to persist this into a secondary XML format, and
then to convert it back from secondary XML format into a DataTable at the
UI. And to do this again, when modified data is sent back to the server.
It'll cut down development expense significantly to just leave this in its
native format and to let the Framework take care of everything for us.
And, you may find some market resistance if you are asking partners to
parse through your XML.
But if we sent back a list of information (as opposed to scalar data item or
items) in XML format, that's exactly what the consumer would need to do in
order to process each row. This is unavoidable for any service which returns
a list or array of data. So why would our own hand-coded XML list
representation be more convenient than the native DataSet XML
representation? Tabular data representation is tabular data representation.
What's the difference whose XML format it is encoded in?
Have you tried strongly-typed datasets? They're nice and RAD, but they at
least define the data via XML Schema. You get to benefit from RAD, your
customers benefit from a strong schema.
Excellent suggestion, I will look into this - thanks!
BTW, I presume you realize that you need to be careful when changing the
structure of the data you're returning?
Remember, you're talking to an ex-COM (hey, I like that term - you heard it
here first! ;-). Keeping an interface constant (or should I say coMstant?)
is second nature to guys like me!

At the end of the day, the vast majority of our Web Services are going to be
consumed by our own application. In this context, RAD development is of
benefit to us. We can always see our way going forward to provide alternate
service methods which could be consumed by eventual partners. Even if our
own in-house services aren't suitable, having the application engineered on
the Web Services platform is going to give us a tremendous boost when it
comes to providing services to even non-.NET clients.

Thanks for your advice,

- Joseph Geretz -

"John Saunders" <john.saunder s at trizetto.comwro te in message
news:eA******** ******@TK2MSFTN GP06.phx.gbl...
"Joseph Geretz" <jg*****@nospam .comwrote in message
news:uX******** ******@TK2MSFTN GP05.phx.gbl...
>Hi John,
>>You should ideally start with the business-level concept, manually
create an XML Schema to describe it, manually create a WSDL file which
will describe the possible interactions with the service in terms of the
schema, and only _then_ go implement a service which may implement these
concepts and operations in terms of DataSets.

I hear what you are saying, but I'm wondering why you're saying it in a
dotnet.framewo rk.webservices forum. The activities you describe, that is
the hand tuning of the XML schema and the WSDL file are specifically
those activities which are *not* necessary for .NET developers. We use a
more RAD approach, basically relying on the IDE to perform this for us
behind the scenes.


Sorry, you're mistaken. .NET does not equate to RAD, esepecially not for
web services. I practiced what I preached on one web service and am about
to do so again on at least one more. This is called contract-first
development.

>The application I am currently devleoping would have two target
audiences.

1. Our own client application. Our developed solution would be
implemented end-to-end using Microsoft .NET technologies using the
aforemention ed RAD approach.

It's not a problem if you want to tie yourself to .NET. That works very
well, until the point when you decide you need to work with something
that's not .NET.
>2. Other vendors in our application market space who might want to
integrate with our application. Web Services would facilitate this type
of integration. Certain vendors might or might not be on the .NET
platform themselves. For those who are, terrific for them, they'll be
able to consume our web services quite naturally with the convenience of
being able to access tabular data in a very convenient format. Those who
aren't should still be able to consume our Web Services, however they'll
have to manually parse through tabular data themselves without the
convenience of the DataTable/DataSet structure since their environments
won't provide the convenience of an object representation of the
DataTable/Set XML.


What's wrong with defining your tabular data with a schema, without
relying on a DataSet?

And, you may find some market resistance if you are asking partners to
parse through your XML.
>>I don't know of many businesses for which "DataSet" is a business-level
concept.

The DataSet/Table isn't a business level concept, however a large amount
of business level data can be represented quite conveniently in
DataSet/Table format. With focus on devleopment convenience (RAD) for our
own application developers, I need a more compelling reason to eschew
DataSet/Tables than simply the fact that it will disadvantage other non
.NET consumers of our Web Service. If it will make it impossible for them
to consume our Web Services, that would be a different matter. But I'm
not hearing that it would be impossible for them, just marginally more
inconvenient .

Am I missing anything?

Have you tried strongly-typed datasets? They're nice and RAD, but they at
least define the data via XML Schema. You get to benefit from RAD, your
customers benefit from a strong schema.

John
BTW, I presume you realize that you need to be careful when changing the
structure of the data you're returning? Once you've published the WSDL,
you shouldn't really be changing the structure of the returned data, at
least not without a versioning mechanism. Again, you may get away with
things like adding columns with some clients, but maybe not with others.

Feb 23 '07 #9
"Joseph Geretz" <jg*****@nospam .comwrote in message
news:Oc******** ******@TK2MSFTN GP04.phx.gbl...
Hi John,
>Sorry, you're mistaken. .NET does not equate to RAD, esepecially not for
web services.

I (and some other developers on the team here) don't quite understand what
you are saying. When using Visual Studio 2005 for Web Service application
development, the IDE takes care of all the wire-up necessary in order to
connect the client with the Web Service. This includes creating the WSDL
on the server and creating the proxy class for the client which consumes
the WSDL and presents a strongly typed interface to the client. Seems
pretty RAD to us.
Microsoft has sold you a bicycle with training wheels on it. Those wheels
are not welded on. Take them off.

When Microsoft first introduced .NET, Web Services were a large part of the
marketing message. In order to encourage developers to jump onto the Web
Services bandwagon, Microsoft did a number of things which I believe were
not good ideas in the long run. They introduced a way to create a web
service that screen-scrapes HTML, for instance. This is a very bad way to
create an application, but makes perfect sense back in 2001, when it was a
useful way to get developers to start using .NET.

Similarly, they introduced the ability to "magically" create web services
simply by putting a [WebMethod] attribute on the public methods to be
exposed. "Look how easy it is!", they said.

But this is not a best practice, and it leads to many of the mistakes that
you and others are making. It is only because of the "magic" going on behind
the scenes that newcomers like yourself can actually ask about how to make
the client use the same class as the server. The question actually makes no
sense at all, but because you're using the training wheels, and thinking
that's how bicycles are made, you have the illusion that the two classes
should be the same and that there's simply some setting you need to change
to make them be the same.

I have similarly heard of a developer who, when he couldn't add a web
reference via http://somewhere/something.asmx?WSDL complained that the
service didn't work, and that there was a connectivity problem. There
wasn't. The "documentat ion" protocol was deliberately disabled. He thought
that "?WSDL" was some standard.

BTW, the client absolutely does _not_ get a strongly-typed interface! The
interface exposed by the server is interpreted by .NET to produce a WSDL
file which the client interprets to produce proxy classes unrelated to the
original classes. If you want strongly-typed, you should use .NET Remoting,
or WCF. The proxy classes are only a convenience.

>What's wrong with defining your tabular data with a schema, without
relying on a DataSet?

There's nothing wrong with it, in general. However consider the context in
particular. The data is retrieved from the database in DataTable format.
That is an implementation detail. What happens when your implementation
changes?
At the (our) UI it's going to be bound to a data-bound widget (very
convenient, for us at least) in DataTable format.
Again, an implementation detail. Your widget will no doubt like you just as
well if you bind it to a custom object exposing strongly-typed properties.
Data binding is not unique to DataTables and DataSets.
Given that this is the case, I'm going to need a compelling reason to
persist this into a secondary XML format, and then to convert it back from
secondary XML format into a DataTable at the UI. And to do this again,
when modified data is sent back to the server. It'll cut down development
expense significantly to just leave this in its native format and to let
the Framework take care of everything for us.
Absolutely. And you will be tied to the framework. If that's part of your
requirement, then you're all set. Many people developing Web Services are
interested in at least the possibility that some client other than .NET will
use their service.
>And, you may find some market resistance if you are asking partners to
parse through your XML.

But if we sent back a list of information (as opposed to scalar data item
or items) in XML format, that's exactly what the consumer would need to do
in order to process each row.
Absolutely not! Why would they need to do any parsing if you've given them a
schema? They'll no doubt do the same thing that you would do - run their
equivalent of XSD.EXE to produce classes from the schema! No parsing
(manual) required.
>This is unavoidable for any service which returns a list or array of data.
So why would our own hand-coded XML list representation be more convenient
than the native DataSet XML representation? Tabular data representation is
tabular data representation. What's the difference whose XML format it is
encoded in?
>Have you tried strongly-typed datasets? They're nice and RAD, but they at
least define the data via XML Schema. You get to benefit from RAD, your
customers benefit from a strong schema.

Excellent suggestion, I will look into this - thanks!
>BTW, I presume you realize that you need to be careful when changing the
structure of the data you're returning?

Remember, you're talking to an ex-COM (hey, I like that term - you heard
it here first! ;-). Keeping an interface constant (or should I say
coMstant?) is second nature to guys like me!
That's what I thought. I'd just point out to you, that the namespace is
somewhat equivalent to the IID - if you change the interface, you need to
change the namespace.
At the end of the day, the vast majority of our Web Services are going to
be consumed by our own application. In this context, RAD development is of
benefit to us. We can always see our way going forward to provide
alternate service methods which could be consumed by eventual partners.
Even if our own in-house services aren't suitable, having the application
engineered on the Web Services platform is going to give us a tremendous
boost when it comes to providing services to even non-.NET clients.
Just keep in mind that the web services platform doesn't include the
training wheels. In fact, you'll find that the aftermarket assumes you've
taken the training wheels off!
John
Feb 24 '07 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
6139
by: K Altsj? | last post by:
If passing a DataSet to a web method for update using ADO.NET and the update fails, the parameter list may get corrupt. The following code example consists of a Web Service and a consumer console application, both written in C# using VS.NET. A tiny MSSQL database is required to run the example: create table test1 (id numeric(1) unique) The console app creates a DataSet and passes it to the Web Service for update. The first execution...
0
2599
by: Bob Davies | last post by:
Hi I have a webservice that retrieves data from a database, this is then returned to the calling client application built in windows forms within a dataset, however upon attempting to create tablestyles to format any of the columns within the datagrid, the exception "Can-not parent objects created on one thread to objects created on another" or words to that effect. I'm not too sure if what I said make sense, but i will add details to...
6
12494
by: rlcavebmg | last post by:
I am new to Web Services and .NET development, and I have a question. I am writing a service that will create a bitmap image and return it to the client. First, I wrote a method that looked like this: public System.Drawing.Bitmap CreateImage() {...} When I tried to create the web reference in my client program, I got an error message stating that the System.Drawing.Bitmap object could not be serialized because it does not have a...
5
19604
by: Stacey Levine | last post by:
I have a webservice that I wanted to return an ArrayList..Well the service compiles and runs when I have the output defined as ArrayList, but the WSDL defines the output as an Object so I was having a problem in the calling program. I searched online and found suggestions that I return an Array instead so I modified my code (below) to return an Array instead of an ArrayList. Now I get the message when I try to run just my webservice...
7
2638
by: David P. Donahue | last post by:
My experience with databases using C# has been pretty limited thus far. Mostly I just use a SELECT statement to populate a DataSet, which is just read-only (mostly for display on a web page), or maybe go so far as to build an UPDATE or INSERT query with a couple parameters and just execute it against the database. Currently, this is all done within a web service, which acts as a kind of protective barrier between the actual database and...
5
4972
by: Jim Murphy | last post by:
In creating a C# web service, I am having trouble returning a DataTable object as the result of a web method. I have no problem returning native types like string or int, but cannot return a .NET DataTable object. The problem occurs when I try to compile the client side C# application (it complains about the DataTable type not being recognized as the return of the web service method). Thanks
0
1775
by: Maart_newbie | last post by:
Hi all, I've got a question about returning the value of a pk-column to a DataTable after inserting a row (via a data-adapter) using MySql5. Here is the SQL and code concerned: //=================================================================== // The table
5
8642
by: Frank Hauptlorenz | last post by:
Hello, I recognized some days ago, that returning a DataTable blocks my WCF-Service. Is this a known bug? If I add this table to a new DataSet() and return this, it works. Thank you, Frank
3
2852
by: Ken Fine | last post by:
This is a question that someone familiar with ASP.NET and ADO.NET DataSets and DataTables should be able to answer fairly easily. The basic question is how I can efficiently match data from one dataset to data in a second dataset, using a common key. I will first describe the problem in words and then I will show my code, which has most of the solution done already. I have built an ASP.NET that queries an Index Server and returns a...
0
9797
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9644
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
10793
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10509
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
10219
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9331
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
6954
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5793
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
3977
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.