This month's T-SQL Tuesday is hosted by Sebastian Meine (blog | twitter) and the topic is joins. He has a whole month worth of topics about joins: A Join A Day – Introduction. My blog post is about something weird I encountered while I was converting some old Oracle code to T-SQL (I encounter all sorts of weird stuff in Oracle code, but let’s stay on topic). Amongst all the usual cursor-madness, I stumbled upon this query:

The Successful Consulting Series is a set of articles that are being written to both, help decisions on joining the consulting field and also, help existing consultants in their professional development initiatives. Please visit, “Successful Consulting Series” for a full listing of each part in this series. Up to now, many of the articles that have been written for this series could be taken for consulting and utilized for fulltime employment or contract positions. However, there are a few aspects to consulting that truly are consulting related and are not nearly as important to the other career choices. Time management is one of those aspects.

The Successful Consulting Series is a set of articles that are being written to both, help decisions on joining the consulting field and also, help existing consultants in their professional development initiatives. Please visit, “Successful Consulting Series” for a full listing of each part in this series. Estimating work is both an art and a skill as a consultant. There isn’t one way or set of standards someone can show you to take and use for every client or project you confront. What a seasoned consultant can do isprovide a basis you can utilize for each potential client, project or task.

Recently I was working on a library to consume a REST API without exposing any of the specifics to the rest of the application. Implementing a common interface and set of custom exceptions was easy enough, but exercising the internal logic was going to be tough. While I could use the live REST API to verify the general logic worked, I had limited options when it came to the full range of HTTP responses and communication failures. Add in the impact those live API calls would have on my build process performance, the occasional failures of my build due the imperfections of talking to a live service, and the overhead of maintaining separation between my test and live data in that service…what I really had on my hands was the beginning of years of random, painful maintenance.

This is day ten of the SQL Advent 2012 series of blog posts. Today we are going to look at SQL Server maintenance <img src=“http://farm7.staticflickr.com/6075/6052402695_6b30a5ea57_m.jpg” width=“174” alt=“gear_shape"style=“float:left;margin:0 5px 0 0;” /> Just like with a car or a house, you need to do maintenance on databases as well. SQL Server has gotten better over the years, there are less knobs you need to turn out of the box but maintenance is still required.

The first stage to tuning a query is the coding. Take a look at the query in listing 1 Note: The query above is utilizing three tables pulled from the database AdventureWorks2012. To create these tables, import them without any indexes into another database. Use a SELECT INTO or any other number of import methods to build the tables. SELECT SUM(OrderQty) AS TotalQuantity ,salesman.LastName ,salesman.FirstName ,hdr.ShipDate FROM [Sales].[SalesOrderHeader] hdr JOIN [Sales].[SalesOrderDetail] dtl ON hdr.[SalesOrderID] = dtl.SalesOrderID JOIN Person.Person salesman ON hdr.SalesPersonID = salesman.BusinessEntityID WHERE Year(hdr.ShipDate) = 2005 GROUP BY salesman.LastName ,salesman.FirstName ,hdr.ShipDate HAVING SUM(OrderQty) > 10 ORDER BY LastName Listing 1

This is day nine of the SQL Advent 2012 series of blog posts. Today we are going to look at something called reinventing the wheel. Just in case your are not familiar with this metaphor or maybe you are not a native English speaker, I will use wikipedia’s description of what reinventing the wheel means. From wikipedia: http://en.wikipedia.org/wiki/Reinventing_the_wheel

Microsoft has made available two pdf files with a nice chart of all the data type conversions. It is pretty much the chart that belongs to the topic CAST and CONVERT (Transact-SQL). Now you have a way of printing a nice looking chart so that you can always reference this. I think this is a great idea, Microsoft should make more of these. The two files are SQL Server Data Type Conversion Chart.pdf which is 1.7 MB, and SQL Server Data Type Conversion Chart_grayscale.pdf which is 1.6 MB

This is day eight of the SQL Advent 2012 series of blog posts. In yesterday’s post SQL Advent 2012 Day 7: Lack of constraints we touched a little upon foreign key constraints but today we are going to take a closer look at foreign keys. The two things that we are going to cover are the fact that you don’t need a primary key in order to define a foreign key relationship, SQL Server by default will not index foreign keys

Introduction A few days ago [Demis Bellot][1] (the creator of Servicestack) was talking about [Smalltalk][2] on twitter. A little discussion came about involving [Alex Ullrich][3]. So my next mission was to learn a thing or two about smalltalk myself. Installation I tried two smalltalk IDE’s. [Squeak][4] (which I couldn’t get to work on Win8) and [Dolphin X6 community edition][5]. So I stuck with Dolphin. And the installation is next, next, next and finish.