linq to sql for stored proc with user defined table as parameter

[Ryan Liu]

Hi,

I am using linq to sql as data access layer, and it works fine for most
store procs.

But seems it can not generate the method for the stroed proc which uses user
defined table type as parameter.
It generates an compile error:

Error 7 Build failed due to validation errors in xxx.dbml.
Open the file and resolve the issues in the Error List, then try rebuilding
the project.

And the method signature in dbml method panel using object instead of
DataTable and no actual method is genereated in cs file.

Is there a way to work around this? Since I am using linq to sql, I hope I
don't have no introduce tradintional ADO.NET data access way back into
project just for this method.

Thanks a lot!
Ryan

 

[Mr. Arnold]

Hi,

I am using linq to sql as data access layer, and it works fine for most
store procs.

It just kills me to see this kind of mis-usage of an ORM solution like
Linq-2-SQL or ADO.NET Entity Framework, where as, all that's being used is
sprocs that defeats the purpose of using a virtual data base, Linq, and
object oriented programming based on objects.

I am not trying to be smart here, but if all you're doing is running sprocs,
then why not use ADO.NET SQL Command Objects and not use an ORM solution?

The best practice with an ORM solution is to not use sprocs and use the
power of the ORM language.





__________ Information from ESET NOD32 Antivirus, version of virus signature database 4104 (20090526) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[Mr. Arnold]

Hi,

I am using linq to sql as data access layer, and it works fine for most
store procs.

It just kills me to see this kind of mis-usage of an ORM solution like
Linq-2-SQL or ADO.NET Entity Framework, where as, all that's being used is
sprocs that defeats the purpose of using a virtual data base, Linq, and
object oriented programming based on objects.

I am not trying to be smart here, but if all you're doing is running sprocs,
then why not use ADO.NET SQL Command Objects and not use an ORM solution?

The best practice with an ORM solution is to not use sprocs and use the
power of the ORM language.





__________ Information from ESET NOD32 Antivirus, version of virus signature database 4104 (20090526) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[Ryan Liu]

It just kills me to see this kind of mis-usage of an ORM solution like
Linq-2-SQL or ADO.NET Entity Framework, where as, all that's being used is
sprocs that defeats the purpose of using a virtual data base, Linq, and
object oriented programming based on objects.

I am not trying to be smart here, but if all you're doing is running
sprocs, then why not use ADO.NET SQL Command Objects and not use an ORM
solution?

The best practice with an ORM solution is to not use sprocs and use the
power of the ORM language.

Of course you have a good point here, but sometime there are still
advantages to use stored proc. That's why linq to sql supports it.

 

[Ryan Liu]

It just kills me to see this kind of mis-usage of an ORM solution like
Linq-2-SQL or ADO.NET Entity Framework, where as, all that's being used is
sprocs that defeats the purpose of using a virtual data base, Linq, and
object oriented programming based on objects.

I am not trying to be smart here, but if all you're doing is running
sprocs, then why not use ADO.NET SQL Command Objects and not use an ORM
solution?

The best practice with an ORM solution is to not use sprocs and use the
power of the ORM language.

Of course you have a good point here, but sometime there are still
advantages to use stored proc. That's why linq to sql supports it.

 

[Mr. Arnold]

Of course you have a good point here, but sometime there are still
advantages to use stored proc. That's why linq to sql supports it.

Well, try having to maintenance a 71 project ASP.NET solution with over 500
sprocs overkill usage to know that everything can be done with an ORM
solution and not have to maintain a sproc or create a sproc again, which
everything can be done with the ORM solution not using sprocs. Those sprocs
are a total nightmare.


__________ Information from ESET NOD32 Antivirus, version of virus signature database 4107 (20090527) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[Mr. Arnold]

Of course you have a good point here, but sometime there are still
advantages to use stored proc. That's why linq to sql supports it.

Well, try having to maintenance a 71 project ASP.NET solution with over 500
sprocs overkill usage to know that everything can be done with an ORM
solution and not have to maintain a sproc or create a sproc again, which
everything can be done with the ORM solution not using sprocs. Those sprocs
are a total nightmare.


__________ Information from ESET NOD32 Antivirus, version of virus signature database 4107 (20090527) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com