SQL Sam and the Evil Twin - Part 1 - Page 2

SQL Sam and the Evil Twin - Part 2

Environment: SQL Server 6.5, SP4

---

---

Sam and Fred examined the SQL Trace from both machines. "You're right, " said Sam. "On Beanie, sp_FindProducts is averaging about 50 milliseconds. On Cecil, though, the query is taking around 250 milliseconds. It's taking 5 times as long!"

"See?" said Fred. "Cecil's gone bad!"

"Let's take a look at your stored procedure," said Sam.

Fred brought the procedure up in Enterprise Manager. It looked something like this:

CREATE PROCEDURE sp_FindProducts
@TYPE varchar(20),
@ARG1 varchar(20),
          
...detail omitted...
          
IF @TYPE = 'HOUSE'
BEGIN
SELECT * FROM products WHERE color = @ARG1
END
ELSE -- Must be of type 'BUSINESS'
BEGIN
SELECT * FROM products WHERE price < convert(money(8), @ARG1)
END

"Interesting," said Sam. "Why is the procedure constructed this way? How is ARG1 used?"

"Actually, it's pretty clever. We found that when people are looking for household products, the most important option is the color. When people are looking for business products, the most important option is the price. So, we combined the two into one procedure, passing either a color or a price as ARG1."

"Did you by any chance try this procedure on Cecil before starting the Do-It-All application?" asked Sam

"Why yes," said Fred. "I wanted to make sure that the 'BUSINESS' products were working properly. Why?"

"I think I know what the problem is now," said Sam. "Let's check."

What did SQL Sam see? Go to the solution now!

Review SQL Sam and the Evil Twin - Part 1

Back to SQL Sam Cases