VS 2008 and SQL Server 2005
-
Has anyone had experience using Visual Studio 2008 to write stored procedures for SQL Server 2005? If so, what are the advantages and what pitfalls exist? I'm in the process of coming up with reasons for my boss to upgrade our Visual Studo from 2003, and we're definitely getting SS2005, so any real info would be very helpful.
-
Has anyone had experience using Visual Studio 2008 to write stored procedures for SQL Server 2005? If so, what are the advantages and what pitfalls exist? I'm in the process of coming up with reasons for my boss to upgrade our Visual Studo from 2003, and we're definitely getting SS2005, so any real info would be very helpful.
If you move to VS 2008, there is LinqToSql that made it possible for us to avoid writing stored procedures altogether in some instances. While you're upgrading, might as well go for SQL Server 2008!
-
If you move to VS 2008, there is LinqToSql that made it possible for us to avoid writing stored procedures altogether in some instances. While you're upgrading, might as well go for SQL Server 2008!
SQL Server 2008 is not in the cards, that is a decision on the part of corporate, not of our department. Frankly, LinqToSQL is not our idea of high-performance - it's simply an easy way to write code. Easy is great for prototyping but not so great when you want to process lots of data. I'm hoping to hear from people who've actually used VS 2008 with SS2005 to write stored procedures in .NET languages, and what problems they encountered in doing so.
-
Has anyone had experience using Visual Studio 2008 to write stored procedures for SQL Server 2005? If so, what are the advantages and what pitfalls exist? I'm in the process of coming up with reasons for my boss to upgrade our Visual Studo from 2003, and we're definitely getting SS2005, so any real info would be very helpful.
pro's * intellisense * unit testing * easy looping * use c# * can use step by step debugger con's (debugger mostly) * debugger is not fully there. I have to restart sql service before debugging stored procedures, so it does not lend it'self to a shared sql development platform. If you don't, debugging will hang. * only one sql program at a time can debug * limited use of linked in libraries. notes. * with the sql dubugger issues it is still a very useful tool.
MrPlankton
(bad guy)"Fear is a hammer, and when the people are beaten finally to the conviction that their existence hangs by a frayed thread, they will be led where they need to go."
(good guy)"Which is where?"
(bad guy)"To a responsible future in a properly managed world."
Dean Koontz, The Good Guy -
SQL Server 2008 is not in the cards, that is a decision on the part of corporate, not of our department. Frankly, LinqToSQL is not our idea of high-performance - it's simply an easy way to write code. Easy is great for prototyping but not so great when you want to process lots of data. I'm hoping to hear from people who've actually used VS 2008 with SS2005 to write stored procedures in .NET languages, and what problems they encountered in doing so.
Did you know you that you can use stored procedures in LINQ? Once you write your stored proc, you can drag it to the LINQ Data Model Designer and it will generate methods to call the proc and the results will be returned as an ienumerable object. I only use stored procs in my application but I use LINQ to call them and get results. VS 2008 has other advantages like better javascript debugging. I still use SQL Management studio to write the stored procs. You can use VS to debug them but it is still easier to write them in Management Studio.
I didn't get any requirements for the signature
-
Did you know you that you can use stored procedures in LINQ? Once you write your stored proc, you can drag it to the LINQ Data Model Designer and it will generate methods to call the proc and the results will be returned as an ienumerable object. I only use stored procs in my application but I use LINQ to call them and get results. VS 2008 has other advantages like better javascript debugging. I still use SQL Management studio to write the stored procs. You can use VS to debug them but it is still easier to write them in Management Studio.
I didn't get any requirements for the signature
ToddHileHoffer wrote:
Did you know you that you can use stored procedures in LINQ? Once you write your stored proc, you can drag it to the LINQ Data Model Designer and it will generate methods to call the proc and the results will be returned as an ienumerable object. I only use stored procs in my application but I use LINQ to call them and get results.
That is VERY interesting. One of the biggest pains with ADO.NET and stored procs is getting the parameters of the stored procedures correctly typed and specified, especially the ones with long, complex lists of parameters (I can think of three that we use off the top of my head). Does it generate lists of parameters, in particular would it force a compile-time or run-time error if a parameter with no default was not specified, or a paramater does not hold an appropriate value? This is the stuff that drives me nuts when I'm debugging T-SQL procedures now.
ToddHileHoffer wrote:
VS 2008 has other advantages like better javascript debugging.
Hear, hear! Can I actually set breakpoints without inserting "debugger;" into my code?
ToddHileHoffer wrote:
I still use SQL Management studio to write the stored procs. You can use VS to debug them but it is still easier to write them in Management Studio.
Hmmm, I can live with that, I think. Was any of this easier if/when you used VS2005?
-
pro's * intellisense * unit testing * easy looping * use c# * can use step by step debugger con's (debugger mostly) * debugger is not fully there. I have to restart sql service before debugging stored procedures, so it does not lend it'self to a shared sql development platform. If you don't, debugging will hang. * only one sql program at a time can debug * limited use of linked in libraries. notes. * with the sql dubugger issues it is still a very useful tool.
MrPlankton
(bad guy)"Fear is a hammer, and when the people are beaten finally to the conviction that their existence hangs by a frayed thread, they will be led where they need to go."
(good guy)"Which is where?"
(bad guy)"To a responsible future in a properly managed world."
Dean Koontz, The Good GuyRight now, we don't have SQL Server debugger capability. It's never installed by default, and I haven't been able to push to have it installed as an option. Is the debugger capability siginificantly better with VS2008/SS2005 than it was, say, with VS2003/SS2000?
-
Right now, we don't have SQL Server debugger capability. It's never installed by default, and I haven't been able to push to have it installed as an option. Is the debugger capability siginificantly better with VS2008/SS2005 than it was, say, with VS2003/SS2000?
Well, only in that you can actually do step by step debugging stored procedures from inside the 2008 ide, but you really need to have sql 2005 installed locally, and with the caveat about having to restart the sql service before each debugging session. There is also one more caveat in that I was never able to jump from my application to a break point in the stored procedure. You have to right click on the stored procedure and click 'step into' in the server explorer and set the arguments passed in, in a dialog, but even with all that it is a very valuable capability in my opinion. I don't believe you could do tsql debugging in 2k or 2003
MrPlankton
(bad guy)"Fear is a hammer, and when the people are beaten finally to the conviction that their existence hangs by a frayed thread, they will be led where they need to go."
(good guy)"Which is where?"
(bad guy)"To a responsible future in a properly managed world."
Dean Koontz, The Good Guy -
ToddHileHoffer wrote:
Did you know you that you can use stored procedures in LINQ? Once you write your stored proc, you can drag it to the LINQ Data Model Designer and it will generate methods to call the proc and the results will be returned as an ienumerable object. I only use stored procs in my application but I use LINQ to call them and get results.
That is VERY interesting. One of the biggest pains with ADO.NET and stored procs is getting the parameters of the stored procedures correctly typed and specified, especially the ones with long, complex lists of parameters (I can think of three that we use off the top of my head). Does it generate lists of parameters, in particular would it force a compile-time or run-time error if a parameter with no default was not specified, or a paramater does not hold an appropriate value? This is the stuff that drives me nuts when I'm debugging T-SQL procedures now.
ToddHileHoffer wrote:
VS 2008 has other advantages like better javascript debugging.
Hear, hear! Can I actually set breakpoints without inserting "debugger;" into my code?
ToddHileHoffer wrote:
I still use SQL Management studio to write the stored procs. You can use VS to debug them but it is still easier to write them in Management Studio.
Hmmm, I can live with that, I think. Was any of this easier if/when you used VS2005?
cpkilekofp wrote:
Hear, hear! Can I actually set breakpoints without inserting "debugger;" into my code?
Yes! The auto generated LINQ Class will create methods to call the stored proc. Each parameter is a variable in the auto generated method. Most T-SQL parameters will be the equivalent nullable type in .net. For instance @input int would be int? input. Null is translated to DBNull. String are not nullable but I think an empty string is translated to DBNull. It is certainly worth trying. It saved me a lot of time on my current project.
I didn't get any requirements for the signature