Bytter rundt på kolonner

Bruger du wildcards i din select?

Ja det gør jeg, er det et problem??

Claus

Med wildcards fortæller du netop at du er totalt lige glad med kolonneorden etc - og i viewet fortæller du så i headeren at uanset kolonne-orden skal første kolonne hedde det, anden det etc etc...

Skift fra at anvende * til specifike kolonnenavne - så er dit problem løst.

Hvis det bare var så simpelt så havde jeg ikke noget problem. Det der sker er at hvis kolonneoverskriften f.eks. er KundeID, så består indholdet af kolonnen i stedet af kundenavn, dvs. at kolonnenavn/overskrift ikke passer med indholdet. Den gør det faktisk hver gang jeg ændrer i den underliggende tabel.

Claus

Alle views skal refreshes hvis du laver om på tabellerne. Åbn dem i design, og klik på gem.

Jeg har et script der kan gøre det, vent lige lidt ...

DECLARE @Name varchar(255)

DECLARE curViews CURSOR 
FOR
SELECT Name FROM sysobjects WHERE xtype = 'V'

OPEN curViews

FETCH NEXT FROM curViews
INTO @Name

WHILE @@FETCH_STATUS = 0
BEGIN 
EXEC sp_refreshview @Name
print @Name
FETCH NEXT FROM curViews 
INTO @Name
END

CLOSE curViews
DEALLOCATE curViews


Start evt med en USE databasenavn, og kør den i QA

Det ser ud til at virke.
Tak

Er det mig?

Ja undskyld Ida det er dig.

Claus

Tak for det.

Forklaringen er den, at SQL Serveren, når den får en forespørgsel, starter med at undersøge hvilken måde den hurtigst kan udføre den. Det handler især om indexer, og om hvordan resultaterne ønskes sorteret. Det bliver til en "execution plan". Fordelen ved views er at der allerede er en execution plan. Den laves når view'et gemmes, og da den altså er klar, kan er view returnere data hurtigere en en "rå" forespørgsel.

Men hvis forholdene ændres, hvis der laves om på kolonnerne eller på indexerne, så skal der laves en ny execution plan. Ellers får man fejl, uforudsete resultater eller man får ikke den performance man ville forvente.

Så kør ovenstående script hver gang du ændrer noget, og som en del af fx en ugentlig vedligeholdelse. Det er ikke specielt tungt at køre.

Ida har naturligvis ret - jeg var faktisk ikke opmærksom på, at SQL Server ikke automatisk genererede en ny query plan.

Men problemet opstår stadig kun når du anvender wildchars i din select - det opstår ikke når du benytter navngivne kolonner.

Tak for det trer.

Jeg leder stadig efter en grund til at benytte wildcards, det skulle være i et system hvor tabeller ændres dynamisk, eller hvad? Ellers må det være dovenskab, og det er en rigtig dårlig grund. Hvis du navngiver kolonnerne sparer du også serveren for arbejdet med at generere listen selv. Og har du virkelig brug for alle kolonner?

I øvrigt - navnet er Lars Danielsen, det er et lille l, ikke et stort I c",)

Vups beklager Lars, det havde jeg ikke bemærket...

Eneste sted jeg ved der er fordel ved at anvende en * fremfor en kolonne er i COUNT().

Anvendelsen af * sikrer at SQL Server kan vælge en indekseret kolonne hvor angivelsen af en kolonne tvinger til SQL Server at tælle kolonnen op uanset om der er et indeks eller ej. 

Du har naturligvis også ret mht dovenskab - specielt ved ad hoc sql i query analyzer - men, synes jeg, ikke mht wildchars i dynamisk ændrede systemer. Bruger man wildchars vil fejlen måske først blive opdaget "højt oppe" i applikationen - og værre, måske først efter et langt stykke tid. Så foretrækker jeg at første forsøg på en tabel-adgang giver en "stop" fejl...