You could build a class that you call to run the stored procs. It could set up the event-handler to catch the InfoMessage event, and package up the result it gets (or nothing, if the event doesn't fire) into a result for you.
I don't know how much code you write for each stored proc call that you do, but I would think that you'd want some kind of "cover" for the raw "prepare input parameters, prepare output parameters, assign values to parameters, call stored proc, return results" boilerplate that you need if you don't write anything higher-level than what ADO.Net provides. Why not take advantage of the fact that you should be writing something like that, and get the "print statement data collection" thrown in for free? At 04:47 AM 6/22/2007, Doug Wilson wrote (in part) >The SqlConnection.InfoMessage event is pretty much what I'm after... Too bad >its an event though. J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
