>Really, if the Web Service is going to be available public, we need to keep straight to the standard.<

Well, I don't even mean a "public" WebService, as in available to the general public, but even with a WebService that goes with your app. If you have an app that you sell to customers, and it accesses SQL Server data on the back-end, and you have WebServices set up to access that data in your app, I think you also need to consider the prospect that your customers may want to write their own apps (Excel or otherwise) using the WebServices. After all, they own the data, not you. They should be able to access their data any way they want to and since you've made it easy to access with WebServices, they should be able to run those from any client.

~~Bonnie


>>Much like having a WebService return a DataSet. That'll work with a .NET client easily enough, but not with other clients unless you use the XMLDOM to parse the object that's returned, since it *is* an object that's returned, not an XML string. So, bottom line with that is never return a DataSet, return DataSet.GetXML() instead.
>>Same goes for this overloading stuff ... it's probably not standard behavior, so don't do it.
>
>
>Those are very good points. Really, if the Web Service is going to be available public, we need to keep straight to the standard. The other stuff (datasets, overloading, etc), may just be used when we do have control over the client.
>
>Good to have that in mind. Thanks. :)