January 15, 2012 at 6:16 am
Having had some exposure to VBA in Excel, I imagine the natural progression for me would be to use VB.NET code in SQL Server, however, it looks as though C# is a more respected language throughout the programming community.
I looked at some code in the MS book relating to 70-433 and there are examples using VB.NET and C# (i.e. both languages are shown to do the same task).
So the real questions I have are:
- Is the learning curve from VBA to VB.NET easier (I'm guessing this answer is YES!...)?
- Is C# used more than VB.NET in SQL Server applications?
- Obviously T-SQL is necessary to get a database working to a relatively 'interesting' degree, but how often does a developer have to delve into VB.NET or C# and can learning these languages take place from a general book on that particular programming language, or does that book have to be related to SQL Server (i.e. SQL Server specific)?
The other realistic issue is time. I'm not sure I can afford to get bogged down with things, but if the learning curve of C# is much harder then I may have to just look at a more natural progression from VBA to VB.NET, although I'd be interested in some feedback before making any decision.
January 15, 2012 at 7:24 am
meridius10 (1/15/2012)
- Is the learning curve from VBA to VB.NET easier (I'm guessing this answer is YES!...)?
Yes.
- Is C# used more than VB.NET in SQL Server applications?
It appears that way, yes (not specific to SQLCLR functionality, C# appears to be used more in general)
- Obviously T-SQL is necessary to get a database working to a relatively 'interesting' degree, but how often does a developer have to delve into VB.NET or C# and can learning these languages take place from a general book on that particular programming language, or does that book have to be related to SQL Server (i.e. SQL Server specific)?
The only time you need any of the .net languages in SQL is when you're writing CLR code. Now, while there are definitely use-cases for CLR, they're not the default for database development, nor should they be. So a database developer will be using T-SQL far more than they'd be using C# or VB.
If you want to learn C# or VB purely for SQLCLR development, rather get a specific book on that. What's allowed in SQLCLR objects is a small subset of the entire of the .Net framework, so if you learn everything there will be a lot you learn that you can't use in the database objects.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
January 15, 2012 at 8:57 am
Many thanks for your response and advice about C# and VB.NET in SQL Server.
I will probably concentrate on T-SQL primarily, as well as looking at getting an understanding of SSRS. This will also make things easier for me rather than trying to cram in a lot of things in a short period of time, which is not necessarily the best solution anyway.
I have a new laptop now, so am looking at purchasing SQL Server 2008R2 Developer edition and using 2008 more than 2005.
In relation to the use of CLR in SQL Server, can you recommend any good internet articles as a start?
February 1, 2012 at 9:36 am
As a VBA developer, I would say that learning VB.NET would be considerably easier for you. At least a lot of the syntax will be the same, although there will be differences. For example, if you want to instantiate an instance of a class in VBA you would do something like this:
Dim oInstance As MyClass
Set oInstance = New MyClass()
The same thing in VB.NET would be simply
Dim oInstance As MyClass = New MyClass()
You can instantiate on the same line as you declare the variable, and you don't need to use the Set keyword.
However, your observation that C# is more prevalent is true. I know both C# and VB.NET, but prefer to write in C#. BTW, just for completeness, the same code in C# would look like this:
MyClass oInstance = new MyClass()
Kindest Regards, Rod Connect with me on LinkedIn.
February 1, 2012 at 9:53 am
This is a little digressing from the post but as T-SQL is the prerequisite and I have had some exposure to VBA, VB.NET would seem to be a good step.
However, my eventual aim is to look at C++ on a purely theoretical level as this may be covered in various courses I might look at in the future and I should start some prep work rather than getting a nasty shock later.
As that is the case I'm a little worried in learning C# as I might get them all mixed up, much like when I started to learn Catalan and Spanish at the same time while having had a good command of French. All latin languages, but not to be learnt at this same time, if possible!
So perhaps now just recognising and amending (where necessary) VB.NET for SQL Server is a viable alternative in my particular case?
February 1, 2012 at 12:42 pm
I think in your case, meridius10, learning VB.NET would be a good choice. And eventually it won't matter that much, because most VB.NET people I know can read C# code when they see it. In fact, it is more likely that someone who is primarily a VB.NET person will read C# code, rather than someone who is primarily a C# person reading VB.NET code.
Kindest Regards, Rod Connect with me on LinkedIn.
February 1, 2012 at 4:14 pm
Thanks for the advice - it is probably more likely that I will go for VB.NET in relation to SQL Server and start, at some point, C++, just as a personal challenge!...
February 2, 2012 at 5:28 am
I would choose VB.NET over C# because SSRS uses VB.NET syntax for expressions and custom code.
February 2, 2012 at 7:47 am
From my understanding T-SQL contains a lot of programming within it. Does that mean that C# or VB.NET are principally used for linking SQL Server to .NET applications?
I have a couple of databases with Access as a front end, so have probably avoided a user need for CLR for now.
February 3, 2012 at 3:32 am
I just have a question relating to ADO.NET and SQLCLR (which is a newbie question!).
Which should I use in SQL Server 2008 R2, or are they both different/both need to be used in linking .NET with SQL Server?
February 3, 2012 at 8:41 am
SQLCLR is used to code SQL Server functions using some flavor of .NET, as opposed to T-SQL. They can be useful for bringing business logic closer to the raw data but they need to be used with caution as they can bring performance overhead, security risks, etc. You can't use it to build all the components of a client-facing app, so in that sense it doesn't serve as a "link" between your client app and the back-end.
So, if you're trying to build, say a MS-based Web app, you'll need to use VB.NET or C# to build your app layer (code-behind, data-access layer, business logic). For a Web app, you also need a sprinkling of HTML/Javascript/CSS to get the presentation layer up and running.
In your data-access layer you would use specialized libraries that contain methods for communicating with a database. ADO.Net is one of these, but if you're using SQL Server in the b/e, MS supplies SQLClient (which is basically an ADO class specifically designed for MSSS) that's very easy to use.
To steer back to your original question: I agree with Gail that your learning curve will be easier with VB.NET (especially with some VBA background). C# requires learning more syntax, but is considered more scalable than VB. Whichever one you choose to learn first, once you have that one somewhat mastered, picking up the other probably wouldn't be too hard. I wouldn't worry too much about mixing them up; the IDEs (e.g. Visual Studio) in which you'd be coding give you lots of visual cues as to whether you're using correct syntax, so you'd know right away if you forgot a } or used Dim in C#.
February 3, 2012 at 9:13 am
meridius10 (2/3/2012)
I just have a question relating to ADO.NET and SQLCLR (which is a newbie question!).Which should I use in SQL Server 2008 R2, or are they both different/both need to be used in linking .NET with SQL Server?
I'm going to sound like a consultant here, but it can't be helped. OK, here goes; as to whether you should use ADO.NET or SQLCLR, it depends. It depends upon what you're trying to do. I've been writing lob apps for 10+ years using ADO.NET, and it's worked great that whole time. I don't have experience with SQLCLR, so I can't say what it gives you more than what ADO.NET gives you. I just took a quick search on SQLCLR and see that it's useful if you're collecting data from several different databases and doing lots of calculations against that data or significant amounts of string manipulation. I've done up to 3 different databases using ADO.NET, and it's worked fine for me.
BTW, assuming that you're doing work more like myself (i.e.: writing lob apps or otherwise doing regular business app development), then going forward it would be better to learn Entity Framework. I've begun to learn that, and it's a change, but WOW is it fantastic for RAD! ADO.NET will be supported for years to come, and I wouldn't be surprised at all if it gets extended, but Entity Framework is where Microsoft is going to be putting more development effort.
Kindest Regards, Rod Connect with me on LinkedIn.
February 3, 2012 at 1:20 pm
Many thanks to Steve and Rod for these comprehensive responses. I'm pretty gald to be making efforts to move away from MS Access as I am beginning to learn so much more about databases through SQL Server.
I will stick with using VB.NET, ADO.NET and SQLCLR when it becomes necessary to do so. I have probably avoided the need for much of this so far as I am using Access 2003 as a front end for SQL Server, but it is definitely useful to know what the .NET options are as well as the use of SQLCLR.
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply