These four scripts list concise information about all Default, Check, Unique, Foreign Key, and Primary Key constraints for the database in which they are run. With minor column modifications, they could easily be unioned to provide a single list. The usual caveat applies about directly accessing system tables. They may change in future versions and/or […]
2003-08-14
1,099 reads
Customers, employees, etc. come and go. They get entered multiple times in inconsistent formats in databases.This simple script finds the duplicates across multiple formats and is easily modified as needed. It's so easy, my grandmother could do it. Oops! No offense Grandma.For very large databases, create and join two temp tables indexed on the namedatetring […]
2003-05-30
206 reads
The excellent script contributed by G.R. Preethiviraj Kulasingham (Preethi) Sri Lanka (contributed 2/20/03, modified 5/22/03) identifies duplicate indexes for the database on which the script is run. It requires User Defined Functions, a feature restricted to SQL Server 2000.This version achieves similar results without using UDFs or creating any other permanent objects. It therefore works […]
2003-05-28
767 reads
This script forms a temporary table containing database and object names and IDS as well as object types for all databases for the server on which this scrip is executed. It is intended to serve as an interim step for additional server wide analysis.
2003-05-16
149 reads
By Rohit Garg
🔍 Demystifying KTLO: A Deep Dive into Keep The Lights On Work in IT...
By Steve Jones
The PASS Summit goes on tour this year, with a September stop in Dallas....
By Kevin3NF
Settings That Could Be Hurting Your Performance If you’ve ever created a new SQL...
Comments posted to this topic are about the item How a Legacy Logic Choked...
Comments posted to this topic are about the item Formatting Dates and Times: The...
Comments posted to this topic are about the item Query Plan Regressions --
For the Question of the day, I am going to go deep, but try to be more clear, as I feel like I didn't give enough info last time, leading folks to guess the wrong answer... :) For today's question: You’re troubleshooting a performance issue on a critical stored procedure. You notice that a previously efficient query now performs a full table scan instead of an index seek. Upon investigating, you find that an NVARCHAR parameter is being compared to a VARCHAR column in the WHERE clause. What is the most likely cause of the query plan regression?
See possible answers