Richard,

>...I don't really have anyone I can turn to and say "hey, I'm stummped here... would you look at this and see if anything jumps out at you." or "That's neat. How'd you do that?" or .... well you got the idea.

Hey, just stick your head out the window and shout out your question. I should hear it OK across the bay. :-)

>So, while I know the words you said, and that they are right, I have gaps in my ability and knowledge that prevent me from knowing if I've done as you suggest.

What Jim was suggesting is to build some business object classes that are independent of the user interface and have methods to query data and return a DataSet, as well as methods to receive a DataSet and save it, etc. Probably you would build them as a separate project in .NET, which would compile to a separate DLL.

You then could use that same business object class in both Windows Form and a Web Form applications by adding a reference to the other project and adding code in the Load of the form to instantiate the business object class.

Aside from that approach, you are stuck with writing the same kind of query and update code in both the WinForm and WebForm. The user interface forms can be built separately since the controls are different between the two. I don't know of any conversion utilities, but perhaps someone has tried. If it's just a 1-form app, probably it's easier to build another form from scratch.

If this form is the start of a more extensive application, you would do well to adopt the separate business object approach.

For a great explanation of these concepts, read the User Guide of Kevin McNeish's Mere Mortals .NET Framework, which, BTW, is a great product to build on. I've just gone through the Jump Start samples and his base class business object and data access classes, along with specialized data-binding controls, made it quite simple to build a couple of forms to query and update data.

http://www.oakleafsd.com/

PS - maybe we should get together for lunch soon and talk about these ideas...