>I figured it out. I rewrote the RunQuery code to return a DataSet.
Yep. =0)
~~Bonnie
>
>
>
>>Ok, I'm still confused on something here.
>>
>>I wrote a method called RunQuery that accepts a query string and returns a DataReader. I then wrote a method
>>called Login which returns the user's Guid as a string.
>>
>>Now I'm working on a GetUser method in which I want to return the user's record as XML:
>>
>>
>> public void GetUser(string sGuid, ref string sMessage)
>> {
>>
>> // Clear the message string
>> sMessage = "";
>>
>> // Define variables
>> SqlDataReader oReader = null;
>> string sQuery = "select * from appusers where usr_guid = '" + sGuid + "'";
>> string sRetVal = "";
>>
>> // Call the method to run the query
>> oReader = RunQuery(sQuery, ref sMessage);
>>
>> // If any data was returned and no error occured...
>> if (oReader != null && oReader.HasRows && sMessage == "")
>> {
>>
>> // Convert the data to XML
>> // <----- What goes here?
>>
>> // Close the reader
>> oReader.Close();
>>
>> }
>>
>> }
>>
>>
>>
>>
>>
>>
>>
>>
>>>
>>Seriously, all our web service methods have a "ref string Message" parameter that will contain any error messages that the server-side stuff may have encountered.
>>>>
>>>>That was the reason I thought of returning an object. An object would contain any amount of data. But I can
>>>>see how it would be cumbersome to return an object.>>>
>>>There are other issues with returning objects ... they may not be recognized by other platforms that may use the Web Service. A few of our customers access some web services from other platforms and we wanted to be sure to maintain platform independence. That's why we return data as a string that's simply the XML representation of the data (MyDataSet.GetXml(), as I already mentioned).
>>>
>>>~~Bonnie