SSIS SCript Component Rant

I certainly don't consider myself an SSIS expert, but I have done some work with it. It is a very powerful tool, but some things bother me about it. The first thing is the inability to debug Script Components in a data flow. I can set breakpoints in a Script Task, but in a Script Component I am left with message boxes and logging. This is a very painful way to try to debug code. Anyone with classic ASP experience can relate (response.write, anyone?). Microsoft went to the trouble of including debugging capabilities in ASP.NET and I certainly hope it is added to Script Components in SSIS in 2008.

Another annoyance is that I would like to be able to "save" a Script Component script as a file and then re-use it in other Script Components. Why can't I do this? I realize I could write a custom component (currently beyond my abilities), but shouldn't I be able to load code from a .vb file?

Lastly, error messages. Why doesn't an unhandled error tell me the Script Component's name instead of the useless, Script_Component_GUID? Just give me something I can easily decipher.

Anyway, I don't want to sound like I am down on SSIS, Script Components particularly, but I just see areas it could be improved and they seem like reasonable things to ask.

Another Microsoft Inconsistency

Brian Knight just did a blog post about how, with SQL Server 2005, using (local) for the server name in a connection times out. Now, his post specifically deals with DTS/SSIS, but his discovery about why is times out, (local) uses named pipes which is disabled by default in SQL Server 2005, is interesting when discussing Linq To SQL. The SQL Server team is disabling protocols to try to make SQL Server more secure, while a the same time the Linq To SQL team has designed Linq To SQL to ONLY use Named Pipes to connect to SQL Server. So while one team is attempting to close a door another is forcing that door to be open. Then again, maybe the SQL Server team doesn't like Linq To SQL, like most DBA's based on my reading, and shut the door for this reason.

Another note is that SSDS (SQL Server Data Services or SQL Server on the Cloud) requires developers to use Linq. As referenced in Andy Warren's It Depends blog.

Feedback on my first published article

Well, Error Handling in SSIS was published this past Monday on SQLServerCentral.com and has been a fairly successful article with over 5000 reads in 5 days. All the feedback I received was positive which was surprising, but very satisfying. I was anticipating some either negative or constructive criticisms/suggestions and have not received any yet. There are also a couple of people who have implemented the solution! The best comment I received was that I should create an SSRS report to package with it. I have done some work on that and have a basic report created which I posted on the discussion thread.

Anyway, I was encouraged by the feedback and hope I can find another subject interesting enough to write an article on and maybe put together a presentation for user groups and a SqlSaturday.

Linq and Linq To SQL

There is an interesting discussion on SQL ServerCentral.com about Linq To SQL based on this editorial by Steve Jones. You will see the DBA's perspective on such tools and, I think, some misunderstanding, particularly about Linq and even Linq To SQL. Linq stands for Language Integrated Query and Linq To SQL is just one implementation of Linq (go here for more Linq implementations), so please when discussing Linq be specific as Mike Taulty has asked in his blog as well.

Basically Linq allows you to access objects with a common syntax something like (in C#):

var query = from p in persons
where p.LastName == "Corbett"
orderby p.Age
select p

The great part is that persons is the object you are querying and it can be a class, a list, an array, a database query, etc... You can also have Linq query that joins objects which is a lot easier to read than nested loops to find matches.

Now back to Linq To SQL. As a hybrid DBA\Developer I see some good things about Linq To SQL, but I also know, as the "protector of data", that having to allow table level access, which you need for Linq To SQL, opens some security holes. I like the way Linq To SQL builds my .NET objects, but wish it made using stored procedures for CRUD (create, update, delete) operations simpler or the default. Since it already has to build the SQL to do the operations, why not have it create a stored procedure? I think it could be an option when building the objects and the designer could ask you for a template for naming the stored procedures.

Also mentioned in the discussion is a mapping tool called iBatis.Net, which looks interesting and, I think has a nice implementation using XML files. It would be nice if MS incorporated something like that in Linq To SQL so you could more easily see, test, and tune SQL statement. Wouldn't it be nice to have Linq To SQL build your objects with all of the method signatures and properties and an XML file that defines the SQL for each of the methods. If it did that, then you could just edit the XML to use stored procedures.

It's important to remember that Linq (including Linq To SQL) is a 1.0 product and that there is definitely room for improvement and we can encourage it by letting MS know what we think the improvements can be.

Remember it is a tool and just like a hammer has certain things you use it for, the same can be said of Linq and Linq To SQL. Make sure it is the right tool for the job!

Error Handling in SSIS published on SqlServerCentral.com

I'm excited to report that my first-ever article has been published on SQLServerCentral.com. While I called it Error Handling in SSIS it would probably have been better titled, Logging Data Errors in an SSIS DataFlow Task, as that more accurately identifies the subject. Nonetheless, it is out there, and it was fun to write. Hopefully I'll get some good feedback from the members at SSC so my writing will improve.

Another Undocumented Database Mail "Feature"

I was setting up Database Mail on a new server, we'll call it Jack1, the other day and, as usual, I could not remember the name of our SMTP server. Having setup Database Mail on other servers, I decided to take advantage of the new modularity of SSMS and open up Database Mail settings on another server, Jack2, so I could find my SMTP server name. I found the SMTP server name and copied over to the new account I was setting up on my Jack1 I finished setting up the account and profile and saved it. Everything should work, right? So I go to Jack1 Database Mail, right-click, and select send test mail. Error, no profiles setup on server! What!? I just finished setting up the Profile. So I right-click and select Configure Database Mail, and lo and behold, there IS NOT a profile setup. I checked the Jack2 server and there I found the new Profile! So it appears that SSMS saves the mail profile to the last server on which you had opened Database Mail setup. I will do a little more testing and post any new findings I have.

Orlando PASS April Meeting

Attended the OPASS meeting on Tuesday night. The featured speaker was Jim Blizzard from Microsoft. He presented Visual Studio 2008 Database Edition and Team System w/ Team Foundation Server. It was a good presentation and there is a lot of cool stuff in Database Edition and Team Foundation Server. Source control, version control, and release control have always been issues with database development, at least in SQL Server, and these products certainly help with that. The most intriguing parts to me were data generation and refactoring. Having a tool to generate consistent test data is neat so you can better test your changes is really nice. Refactoring is just as nice, change a column name and have the change propagate to all the places that column is referenced (sp's, views, constaints, keys) is very nice. Of course, for someone like myself, who works in a small shop, a lot of the Team Foundation Server features are overkill and the money to spend on it fairly significant. I'd really like to see Microsoft include the features in the Database Edition in Visual Studio Professional. There are a lot of guys like me who have to do it all and having the ability to have a database project would be nice. The other issue is, why didn't this functionality get in to SSMS, and/or is it in SSMS 2008?

Overall it was a good meeting (KForce also had some time) with a turnout of about 30 people. User groups are a good place to network, learn something, and just have a good time. Take the opportunity to check one out in your area. If you are in the Orlando area here's where you can find out more about OPASS. You can also find out about a SQL Server group in your area at the Professional Association for Sql Server web site.