Bonnie...

Thanks for responding...however, in reading your response, it occured to me that I might not have completely described what we're doing. What I might not have been clear on is that we're passing the dataset all the way back to the Winform. Let me try this again...

Let's say I'm a financial administrator, and it's my job to resolve financial deductions. The following happens:

1) I sign on to the Winform, and I click a button that essentially says, 'retrieve all my new deductions.'

2) That fires a call to the web service with a request to retrieve deductions for user XYZ.

3) The Web Service calls a middle-tier component which either does SQL pass-through or calls a stored proc that retrieves the data from SQL Server.

4) The middle-tier passes the dataset containing the data (might be 50 deductions) all the way back to the Winform.

5) The winform binds the result set to a data grid, and the user scrolls through the list, reviews each one, and decides which one to edit. The user might also run a report on the deductions...since we've already pulled the dataset back, we can run crystal run-time locally without the need to go back to the server for anything.

6) Any changes the user makes are packaged up as a simple data set, and sent back to the middle-tier [through the web service], which performs the update via a transaction manager as part of our data component.

So yes, access to data is through a web service that in turn calls server-side components in C#. However, we're passing the dataset all the way back to the winform, to give the local UI the best performance.

The person I talked to felt that it was better to NOT bring the dataset all the way back to the Winform. However, because of the UI requirements of our app, I just don't see that as practical...but maybe I'm missing something.

Thanks,
Kevin