This is where we start the decline phase in our story. Our temporary procedures existed as a bridge from the old procedures which took
ClientIDand new procedures which will take
ProfileID. With our final versions of procedures, we replace
@ProfileIDin the input parameters and update any conditional logic within filters to use
The only remaining use of
ClientIDin these procedures is as an output in select statements, as we still need that for the old code; by this time, all of those references are
ProfileID AS ClientID. Otherwise, these new procedures are built around
We still have the original procedures that the application code uses and they reference our now-finalized procedures. These procedures are now transition procedures—we need them right now but as we move application code over to the new procedures, we can deprecate these. But I’m getting ahead of myself a little bit.
Click through for the full story as well as a bunch of pictures which completely understate the vastness of work done.
I’m going to keep this intro short and sweet. I’d like to say it’s because I know these roundups are for acknowledging and thanking the people who have contributed, and this is the case! Mainly though it’s because I wrote this bit last and I’ve already written… checks … 2,795 words!
So thank you one and all for participating. I’ve never thought the posts would raise feelings of happiness, sadness, thoughtfulness, and appreciative-ness that this one has.
Read on for the full list and Shane’s thoughts.
To clarify, the extension in ADS is like XEvent Profiler in Management Studio (which also is built using Extended Events). The name “SQL Server Profiler” is confusing, as this is not the same tool (UI) that’s been available since SQL Server 7.0.
To install the extension, click on it, and then select Install. Once it’s installed you can select Reload and it will move into the top half of the window under Enabled. Notice that when you select the extension, information about how to use it also appears.
Erin has a lot of useful information here, so check it out.
The first thing you’ll notice is what Oracle refers to as an INSTANCE is different to what SQL Server calls one.
Oracle’s instance is most closely related to what SQL Server calls their database, (although it includes the files that Oracle includes in their description, too) and the Oracle home is *relatively* SQL Server’s version of an instance.
Read on for a deeper comparison from someone who has spent quite a bit of time working with both platforms.
When first learning SQL Server, I had the brilliant idea of defining every column on my table as VARCHAR(8000). After all, the VARCHAR datatype only consumes as much storage space as the string itself (plus two bytes), so even if I defined the max length of a column as 8000, I wouldn’t be wasting storage space if my data was smaller than that.
My development life would be easier too since I wouldn’t have to think about the kind of data I was storing in my columns; I could define everything as VARCHAR(8000) once and never have to go back to make any changes. Brilliant!
While I was correct about not wasting storage space, it turns out the idea of making every column VARCHAR(8000) is a terrible idea.
Click through to learn why.