Bliži se kraj godine i jedno pitanje sa kojim se kao developer možda sretnete u to vreme, a pogotovu ako radite sa bazama koje niste samo vi održavali, je „Da li je negde u nekoj proceduri ostala zakucana godina?“

Alata i programa za pretragu procedura, viewova i funkcija ima dosta na tržištu, uglavnom svi funkcionišu dobro, a mnogi su čak i besplatni. Međutim, problem koji se javlja kod svih tih programa je, što u rezultate pretrage uvek ulaze i komentari unutar procedura, odnosno vraćaju među rezultate i procedure gde se termin koji tražite nalazi unutar komentara. To najčešće nije problem, ali kada se traži godina ili datum može biti. Ukoliko redovno vodite u zaglavlju procedura evidenciju izmena, ili imate primere poziva koji u sebi uključuju datum, verovatno da ćete za pretragu termina „2014“ dobiti sve procedure koje ste menjali u toku 2014. godine.

Naravno, postoji i opcija da sami pretražujete sistemske viewove, ali problem ostaje isti.

Da bismo prevazišli problem, mi smo vam pripremili jedan upit – proceduru koja radi pretragu, ali pre toga uklanja sve komentare i pretražuje samo kod.

Sintaksa koju svi često volimo da koristimo je SELECT * INTO #temp FROM.. koja nam omogućava da brzo kreiramo temp tabelu od rezultata koji upit vraća.

Verovatno je i svako ponekad poželeo da to isto iskoristi i da rezultate stored procedure na sličan način smesti u neku privremenu tabelu, ali već prvi pokušaj će pokazati da takva sintaksa za procedure ne postoji.

SELECT * INTO #temp FROM EXEC dbo.usp_Kefalo_Procedura; --?!?!
EXEC INTO #temp dbo.usp_Kefalo_Procedura; --?!?!

Jedino ispravno rešenje je unapred kreiranje temp tabele, i njeno punjenje INSERT..EXEC sintaksom:

CREATE TABLE #tempTabela (Kolona INT);

INSERT INTO #tempTabela
EXEC dbo.usp_Kefalo_Procedura;

Međutim, ukoliko postoje određeni uslovi, moguće je iskoristiti funkciju OPENROWSET i postići željeni cilj. Komanda bi izgledala ovako:

Procedure sa ulaznim parametrima se koriste da bi se poboljšale performanse sistema, kada postoji mnogo zajedničkih upita istog oblika. Prilikom prvog izvršavanja procedure (pod prvim se podrazumijeva izvršavanje nakon (re)kompajliranja), SQL Server kreira keširani plan izvršenja (execution plan), koji koristi prilikom sledećeg poziva. Ovakvo ponašanje (koje predstavlja ponašanje SQL Servera po dizajnu) je poznato pod nazivom parameter sniffing.
Kreirani plan je prilagođen prvoj prosleđenoj vrijednosti parametra i u zavisnosti od njene raspoređenosti na izvoru, može biti izabran tako da koristi npr. nonclustered index seek. Takav plan može da odgovara ostalim vrijednostima parametra, ali može da se desi da nekoj vrijednosti parametra više odgovara korišćenje clustered index scan, a ipak će koristiti keširani plan.
Tada procedura traje mnogo duže nego što je uobičajeno, dešava se da se izvršavanje poveća sa minut ili dva na preko sat vremena. Kada pokušate da zaključite koji upit u proceduri je iznenada počeo da pravi problem, zaključićete da se tijelo procedure, sa proslijeđenom vrijednošću parametra pušteno kao upit izvršava za isto vrijeme kao procedura ranije i da problem nije u tijelu procedure.
Problem je opisano ponašanje SQL Servera, odnosno