tags:

views:

145

answers:

1

By edict, we're using stored procedures for all interactions with our database.

By organizational directive, we're using table value parameters in some of these stored procedures, specifically the ones I need to use.

By legal edict, we can't use nHibernate or anything under LGPL (though, if necessary, we can fight back on that).

Are there any OR/M (object-relational mapper) frameworks out there that support table value parameters into stored procedures?

I've already investigated the crap out of Linq to Sql and Entity Framework v1, and I know that it's fundamentally not supported now, and L2Sql will probably never support it.

Anything out there, commercial or free? I really don't want to write hundreds of lines of boilerplate to decode the results.

+1  A: 

So, write your own, at least for these stored procedures.

Are there so many of them?

It's way to late for me to try this, but you can: take one of your stored procedures. Create a new typed dataset in Visual Studio. Drag this SP from Server Explorer onto the design surface. See whether the parameters collection is correctly updated.

I'm not suggesting this as your ORM technology, only as an experiment to see whether table-valued parameters are supported by this designer (and, presumably by the designer for SqlCommand, SqlDataAdapter, etc).

If it works, then it gives you at least a bad way of quickly generating the code you'd need in an ORM: copy the code from the dataset.designer.cs file into your own code.

It's then possible, if you really need to know, to figure out what the DataSet Designer is using to pick up the parameters - you could then use it yourself, in your own code generation.

John Saunders
Three troublesome stored procedures for now, but many more will be coming down the line.The designer, along with some custom downloaded T4 templates, are getting me my nicely generated response code. This copy pasta is an option in my short term, but is not going to be a great org-wide solution in the long run, and kind of defeats the ORM promise of maintainability. I'll more likely push xml parameters to the db team than take this route (a battle in itself).
askheaves
No, really, I didn't mean this as a solution. I meant if it works, then find out how the DatSet designer pulls the information on the parameters. Then use that same technique in your T4 templates.
John Saunders
No joy. The typed dataset designer hates stored procedures, failing out with an annoying Messagebox message. "Mouse drag operation failed. Execution of user code in the .NET Framework is disabled. Enable "clr enabled" configuration option." Dragging tables works fine. What I'm really looking for is one of the several dozen existing OR/M frameworks to support this now-standard data type before I start pushing back against the db team's ideas of how things should be done.
askheaves
Huh? What version of Visual Studio are you using? Does it fail with SP with no table-valued parameters? I just did this recently.
John Saunders
Just now got this to work with VS2008 and SQL2008. Dragged a function from AdventureWorksDW2008, created an SP to call the function, then dragged that to the design surface as well. Both worked and created what looks like a good Parameters collection.
John Saunders
VS2008SP1, Sql2008, and I tried with a non-TVP function first. Same result.I REALLY appreciate you spending the time here with me, but if I'm going down the "replicate strongly typed dataset behavior" route, I've got better, cheaper options available. I've dropped two days on this, and I'm looking for a white knight to support a now-standard Sql behavior, or a no-go answer.
askheaves
What's the database compatibility level of the database you tried this with? Also, if you have a moment, see if you can try it with the AdventureWorksDW2008 database. I'm not just asking on your behalf; I really don't like having a non-repro around this technique since it can be an actual, longer-term solution for some problems, and at least interesting for others.
John Saunders