Tony, As far as I'm aware Linq to Entities doesn't support Table Valued Parameters. We're using EF4 on a pretty big project at the moment, and the few procs that we've needed to pass tables up to we've just added partial methods on the generated object context, and rolled our own ADO.Net code to make the calls. Works quite well, but not quite as nice.
Neil. On 14 September 2010 09:19, Tony Wright <[email protected]> wrote: > Hi all, > > > > I am currently attempting to pass a set of data into a stored proc via LINQ > to SQL. The data type of the server column receiving the data is “xml”. The > data type of the LINQ to SQL designer column is System.Xml.Linq.XElement. > Usually, this executes successfully, but every now and then the application > refuses to compile, claiming that “Mapping between DBType ‘XML’ and Type > ‘System.Xml.Linq.XElement’ in column AggregateXML of type MyTable is not > supported.” > > > > But like I said, most of the time it works. The data makes it into the > stored proc via this column. Which is very frustrating, because at the > moment it’s a mostly working solution so we need to leave this in there. > Unfortunately, when the error occurs, we can no longer get the application > to compile, so we have to get out of Visual Studio and get back in after > resetting it (running VS with no packages works). > > > > Also, using XML to pass sets of data is actually not very efficient. I’ve > seen the stats and they’re not pretty. So my preference would be to utilise > table-valued parameters when passing data into the stored proc. But at the > moment LINQ to SQL does not support table-valued parameters. > > > > What I am wondering is whether LINQ to Entities offers table valued > parameters. I know it hasn’t in the past, but I am wondering if anything has > changed here? > > > > Or whether there are any alternatives to this (other than passing a > delimiter separated string of values, of course, which doesn’t work in our > case for other reasons). > > > > Regards, > > Tony
