So would a tool handle keeping my Stored Procedure structures consistent when I am returning the same object?

Hillsboro, Oregon? Is that new?

>Mike -- I just wanted to second what Paul said about using a tool for this ... either store-bought <g> or homegrown. We use a homegrown tool ... it started out very simple in the early days (similar to Paul's ... we'd just give it a Stored Proc name and it would generate our class, which in our case was simply an .xsd). Now the tool has been tweaked to do a whole bunch of other stuff besides this and I don't even know what it's doing anymore, it got really complicated (I'm not in charge of it).
>
>~~Bonnie
>
>
>
>>>>Trying to map all of my Select Stored Procs to the same Business Object is getting tough. I had hoped other developers would offer their methods to make sure the structure stays in sync.
>>>>
>>>>Thanks for the reply. I think it's a good idea and was looking for somebody to either raise a red flag or say it was a good idea. Thanks!
>>>
>>>I think a lot of us are using various tools like Codesmith, My Generation, homegrown, etc. to build our Entities for us automatically. Essentially the tool calls and/or looks at a given table/view/stored proc. then builds the wrapper class based off of it.
>>>
>>>Most of my stored procs. where I do this map fairly reasonably onto an existing entity built from my tables (that is, the stored proc. returns a subset or superset of the table). I've been pretty lazy so far - in the few cases where I wanted strongly typed access to those additional fields, I just manually added the code. In most other cases I just fall back to accessing them via table.Rows[0]["RowName" style syntax. Ugly but it doesn't seem to come up that often in the stuff I've been working on.
>>
>>I see. Thanks for the input.