Crazy enough, the last two are correct. It seems that unlike every other language I’ve worked with, all variables are scoped to the same local scope regardless of where in the script they are defined. Demo the first
Wanna see something even more crazy? Check this version out
I should note that I wanted a submit button.
My first gut reaction was that this code is broken and would not run. To my amazement code ran just fine. Now came the hard part, which was to figure out what the code was doing because I have never seen this syntax before. Since I did not understand what I was looking at I could not BING “weird join syntax” to get an answer. As a developer, I learned long time ago to break down code into smallest possible chunks to get the answer.
After I have figured out the relationship between tables, I was able to understand what query was doing. To be able to read query better it can be rewritten in the following way.
Do read Vlad’s post. I’ve seen terrible misuse of this plus right outer joins, and I don’t know if I’ve ever seen a case where using this syntax made the code easier to understand.
The below is a link to my GitHub repo of my personal collection of scripts. BTW this isn’t all of the scripts, but is probably 50% of the ones I have lurking around.
These are either scripts I have developed in my own time over the years, or adapted from various other websites which I found handy at the time for whatever reason.
Where I have remembered that web site (like most people, which is unfortunately almost never) it was typically from sites like stack overflow etc, and if so I have tried to cite it as such to provide credits.
Click through for the link to Rolf’s repo.
My results are as below. I have 1000 records in the table. This tells me that I have 82 occurences of age cohort 0-5, 8.2% of my dataset is from this bracket, 82 again is the cumulative frequency since this is the first record and 8.2 cumulative percent. For the next bracket 06-12 I have 175 occurences, 17.5 %, 257 occurences of age below 12, and 25.7 % of my data is in this age bracket. And so on.
Click through for the T-SQL and R scripts.
This past week I needed to run some queries on production to verify there were indexes added on a table. There were several scripts that needed to be run and the last one was the addition of the indexes. The query given to me was something like the followingSELECT * FROM LinkedServerName.DatabaseName.sys.indexes WHERE object_id =(OBJECT_ID('TableName'))
So I ran the query..nothing. Aha maybe they are still running the scripts before that, setting up replication, snapshotting the table etc etc. I will check again in a bit I thought.
Click through for the full reason and how to fix your code in this situation.
Pro: We get a separate query plan for each combination of parameters so performance is great. (Well, as good as can be anyway.)
Con: Maintance stinks. We need 16 different queries when we have 4 parameters and the numbers increase dramatically as we add additional parameters. So any change we make to the base query will have to be changed 16 times, and/or adding a new parameter means careful logic and adding a bunch of new queries.
I’d consider this a gateway for Erland Sommarskog’s article on the topic.
So let’s test out this bad boy using the WideWorldImporters database, see if we can find everyone with the first name of Leyla.
Simple right? And because [Sales].[Customers] uses the full name, we have to use
Now a developer comes along and says “Wait a second, my sister is Leila”. So we try to cheat and add a wildcard in there.
Leonardo!? Well I suppose he does count in this situation, but there’s 2 characters between the ‘e’ and the ‘a’ and I only wanted one.
Click through for a couple pattern matching tricks and look for ways to avoid Lejla in your life.
Today’s less-than-ugent challenge was to un-pivot the output of RESTORE HEADERONLY. I thought for certain someone else, somewhere, at at some time must have wanted to do the same thing. So I asked the Twitterverse, but no one responded. I guess I’ll have to make do myself without the easy button. No worries, though. We can do this!
Metadata tables are good friends at times like these.
To come up with a solution, I first thought about how to solve it with a traditional cursor. I won’t provide a cursor solution here, but it would involve looping through the rows in order and finding the first and last employee rows. When the last EmpID doesn’t match the next EmpID, then the previous row is the last call for the previous EmpID and the current row is the first call for the next EmpID.
NOTE: The solution to this problem assumes that there are at least two calls per shift.
In 2012, four T-SQL window functions became available that let you look at expressions from different rows: LAG, LEAD, FIRST_VALUE, and LAST_VALUE. For this puzzle, LAG and LEAD seemed to be the answer. In this case, I used the optional default parameter to replace any NULLs with -1.
This is a particular solution for the Gaps and Islands problem; here’s Itzik Ben-Gan on the topic.
If we were to hit F5 (or however you execute your TSQL statements in SSMS) without highlighting any statement(s) they would all be executed, one batch after the other. Even if one batch were to fail or we had a THROW in that batch it would fail at that point but execution would continue immediately after the next GO until the end. This is where SET NOEXEC ON comes into play. If I add that at the beginning of the script all succeeding code would not be executed. The statements would only be compiled and not actually run. It would look like this:
SET NOEXEC ON;
PRINT ‘Got Here 1’ ;
PRINT ‘Got Here 2’ ;
PRINT ‘Got Here 3’ ;
PRINT ‘Got Here 4’ ;
This is a useful “accidental F5” protection: you can put it at the top of your long script to keep from running the whole thing at once.