Programmers like new toys that they can play with, be it a second monitor, a new IDE, or a new programming language. They also like to feel that they are learning new things and not getting assigned to the technological scrap-heap and so will inherently favour (for example) C#3 above VB6 even when the final solution might be suboptimal.
I found myself drifting into this mindset recently when prototyping a design for component to fit in with an existing framework of COM components.
The component needed to call out to SQL Server 2005 to start an Agent Job. My first instinct was that I had to interface with SQL 2005 Native Client components through the .NET libraries. I envisaged something something like this:
//...get the connectionString somehow... string connectionString = "Data Source=SOMESERVER;Initial Catalog=SomeDatabase;Integrated Security=SSPI;Provider=SQLNCLI.1;"; OleDbConnection oleDbConnection = new OleDbConnection(connectionString); ServerConnection serverConnection = new ServerConnection(oleDbConnection.DataSource); Server oSqlServer = new Server(serverConnection); JobServer oAgent = oSqlServer.JobServer; Job oJob = oAgent.Jobs["Test"]; JobHistoryFilter oFilter = new JobHistoryFilter(); oFilter.JobName = "Test"; oJob.Start();
…or something similar therein.
The component would have to expose a COM Interface and be registered using REGASM, which would requrie manual intervension in the shipping process.
In addition to this, I would have neededed to organise for the SQL 2005 Client tools installed on four servers and undertake regression testing of the applications on these servers to inspire confidence that this hadn’t broken anything.
To be frank, it all seemed a little onerous and overcomplicated. Apart from simply wanting to use C#, the reason for this doing this was based on an assumption that I needed the .NET library code to hook into SQL Server and that there was no other way. Really? Have you ever heard such nonsense?
Without realising, I’d very nearly falling into the Second System Effect trap (of sorts). All I really had to do was make a call out to the SQL Server sp_start_job to achieve the same effect, and all I needed was trusty old MDAC 2.8. This meant I could write it in VB6 to fit in with existing framework components with none of the impact or complication inherent with the C#-developed component.
So, I set about writing a little test application as proof of concept. It looked something like this:
Private Sub Command1_Click() Dim connection As New ADODB.Connection Dim connectionString As String connectionString = "Data Source=SOMESERVER;Initial Catalog=SomeDatabase;Integrated Security=SSPI;Provider=SQLOLEDB.1;" Call connection.Open(connectionString) connection.Execute ("EXEC msdb.dbo.sp_start_job @job_name=N'Test'") MsgBox ("Success") End Sub
But I really wanted to use C#! However, in this instance it just wasn’t feasible.
So, in conclusion, don’t get blinded by shiny new toys or by a desire to improve oneself, don’t simply dive into the first solution that you come across, and remember, complication is ruination!