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.
Monday, April 28, 2008
Friday, April 25, 2008
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.
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!
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!
Monday, April 21, 2008
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.
Labels:
Published Articles,
SQL Server,
SqlServerCentral,
SSIS
Thursday, April 17, 2008
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.
Thursday, April 10, 2008
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.
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.
Monday, April 7, 2008
Ghost of SQL Server 2005 Database Mail Reply To, Resolution?
Microsoft has confirmed this as a bug which has been fixed for SQL Server 2008. If I, or you, want it fixed for SQL Server 2005 a QFE needs to be submitted.
I'm not sure I like the fact that I need to go another step to get this corrected. Fortunately I was not using this feature successfully and then had it stop after applying updates. If I had been using it I would be very upset that the fix released for 2008 was not made compatible with 2005.
What do you think?
I'm not sure I like the fact that I need to go another step to get this corrected. Fortunately I was not using this feature successfully and then had it stop after applying updates. If I had been using it I would be very upset that the fix released for 2008 was not made compatible with 2005.
What do you think?
Subscribe to:
Posts (Atom)