Hvordan undgår man prefix af user for user functions

Jeps, det kan ikke ændres ;O)

Desværre må man jo nok sige!

prov med CREATE function dbo.mod (@dividend INTEGER, @divisor INTEGER)

derefter skulle du vaere i stand til at bruger select mod()

NU var 'mod' måske lige simpelt nok, og ja den kunne godt køre som dbo.
Men jeg er interesseret i at min funktion kan evaluere forskelligt afhængig af brugeren, under ORACLE er det muligt umiddelbart.

saa er det ligesom janus siger, ikke muligt, dette er selvfolgelig fordi at mssql skal vide hvilken funktion du vil kore, og hvis der er flere brugere der har den samme funktion ved den ikke hvilken den skal bruge. Dog er det saadan at den vil tage en funktion under sit eget navn forst, dvs. at har du dbo.funk og user.funk og er logget ind som user vil den bruge user.funk hvis du ikke specificere en bruger.

bjornicle> ...og er logget ind som user vil den bruge user.funk hvis du ikke specificere en bruger.

Men jeg kan jo netop ikke undgå at specificere en bruger?!

det lyder maerkeligt, nu bruger jeg sjaeldent funktioner her som ikke er dbo, faktisk er det lang tid siden at jeg har brugt en funktion i mssql, saa det kan godt vaere at min hukommelse paa dette omraade er lidt rusten, men jeg mener meget at den gerne skulle defaulte til sin egen bruger. Jeg vil lige prove at teste det her

Nu har jeg testet det og jeg faar samme resultat som dig, jeg maa have husket forkert saa

Kedeligt, jeg var sikker på at det måtte være en fejl, det virker helt fjollet man ikke kan

Som janus siger "det kan ikke ændres"

Men faktisk er det værre end som så. Hvis du *ikke* prefixer tabeller, views, stored procedures etc med owner så vil optimzieren skulle rekompilere objektet og lave ny query plan for hver access.

Prefixer du, så kan den tidligere query plan genbruges...

Med andre ord: Man skal *altid* prefixe med object-owner.

trer> det lyder interessant at den kompiler en ny plan hvis man ikke specificere owner, har du evt. et link til lidt mere information om dette ?

Ved du ogsaa om det gor sig gaeldende hvis man bruger bind variables i sin sql, da jeg med dette har faaet kanon resultater i benchmark tests.

Du kan finde mere om det på microsofts hjemmeside - de har nogle artikler om performance optimering på sql server.

Problemet opstår ved, at du forbinder med en non-dbo bruger. SQL Svr forsøger så at finde et objekt under aktuelle bruger, konstaterer at det ikke findes, og forsøger så at finde det ejet af dbo. Disse to skift gør, at query plan etc skal gendannes.

Bindvariabler er en god ting, sql server forsøger at parameterisere alle queries, men er sandt at sige ikke god til de ting.  Det betyder at nogle gange vil fx denne sql

delete from mytable where id = 4

blive auto-parameteriseret til

(@val =4) delete from mytable where id = @val

andre gange vil den ikke kunne finde ud af det!  Derfor får man fyldt sql servers cache med ganske enslydende statements hvilket giver overhead. Performancemæssigt bør man altså altid parameterisere en query - eller et kald til en sp.

cachen kan du tilgå i tabellen syscacheobjects. Her kan du se om en query er parameteriseret, hvor meget ram den bruger og hvilke base(r) den tilgår. Faktisk kan du bruge informationen til at beregne ramforbruget pr database på din sql server!

Bemærk også kolonnen UID. Indeholder den værdien -2 (minus 2) kan querien bruges af flere forskellige brugere - i alle andre tilfælde skal den rekompileres etc.

Hvad sker?

-do-

-do-