---

Hej NG,

Jeg har en stored procedure som tager et tal som input, nu kunne jeg godt
tænke mig at kalde den stored procedure noget ala sådan her,

select tal from tabel

for each tal in tabel
begin
stored procedure tal
end

Nogen der forstår hvad jeg mener?

Kan man gøre det?

/Kasper

---

Som svar på skriblerier forfattet af Kasper Kamp Simonsen

> Jeg har en stored procedure som tager et tal som input, nu kunne jeg
> godt tænke mig at kalde den stored procedure noget ala sådan her,
>
> select tal from tabel
>
> for each tal in tabel
> begin
> stored procedure tal
> end
>
> Nogen der forstår hvad jeg mener?

Jada
>
> Kan man gøre det?
>
Jeps, du kan gøre det vha cursors, men hvad præcis er det du gerne vil?
cursors er ret cpu-tung for et rdbms at håndtere

En anden konstruktion (ny sp) kunne fx være noget ala

select <fieldlist> from <tabel>
where tal in (select tal from <tabel>)

mvh/Peter Lykkegaard

---

Peter Lykkegaard wrote:
>

<snip>

> Jeps, du kan gøre det vha cursors, men hvad præcis er det du gerne vil?
> cursors er ret cpu-tung for et rdbms at håndtere

Det kommer da bestemt an på, hvilket rdbms vi taler om. Jeg har aldrig
hørt den påstand før. Min primære reference er Sybase og Ingres, og der
har jeg aldrig hørt om problemer med cursors.


--
Kristian Damm Jensen | Feed the hungry at www.thehungersite.com
kristian-damm.jensen@cgey.com | Two wrongs doesn't make a right,
ICQ# 146728724 | but three lefts do.

---

Som svar på skriblerier forfattet af Kristian Damm Jensen

> Peter Lykkegaard wrote:
>>
>> Jeps, du kan gøre det vha cursors, men hvad præcis er det du gerne
>> vil? cursors er ret cpu-tung for et rdbms at håndtere
>
> Det kommer da bestemt an på, hvilket rdbms vi taler om. Jeg har aldrig
> hørt den påstand før. Min primære reference er Sybase og Ingres, og
> der har jeg aldrig hørt om problemer med cursors.

Ikke problemer som sådan, hvis man ikke holder tungen lige i munden eller
bruger det uhensigtsmæsseig så kan det give endog store problemer
Det er at foretrække at bruge set operationer fremfor iterative operationer

Jeg ved ikke om MSSQL har en direkte dårlig implementering af cursors
Men den generelle holdning er undgå cursors hvis det er muligt

Jeg ved ikke lige i hvilke sammenhænge du bruger cursors

mvh/Peter Lykkegaard

---

Peter Lykkegaard wrote:
>
> Som svar på skriblerier forfattet af Kristian Damm Jensen
>
> > Peter Lykkegaard wrote:
> >>
> >> Jeps, du kan gøre det vha cursors, men hvad præcis er det du gerne
> >> vil? cursors er ret cpu-tung for et rdbms at håndtere
> >
> > Det kommer da bestemt an på, hvilket rdbms vi taler om. Jeg har aldrig
> > hørt den påstand før. Min primære reference er Sybase og Ingres, og
> > der har jeg aldrig hørt om problemer med cursors.
>
> Ikke problemer som sådan, hvis man ikke holder tungen lige i munden eller
> bruger det uhensigtsmæsseig så kan det give endog store problemer.

Enig. Man skal være inde i låseproblematikken, når man bruger cursors,
ellers er man på dybt vand. Og her er det nødvendigt at være
velbevandret i den specifikke system, man kan som hovedregel ikke nøjes
med en generel viden om databaser.

> Det er at foretrække at bruge set operationer fremfor iterative operationer

Absolut enig. Men der findes desværre situationer, hvor
mængdeoperationer ikke er mulige.



--
Kristian Damm Jensen | Feed the hungry at www.thehungersite.com
kristian-damm.jensen@cgey.com | Two wrongs doesn't make a right,
ICQ# 146728724 | but three lefts do.

---

Som svar på skriblerier forfattet af Kristian Damm Jensen

> Peter Lykkegaard wrote:

>> Jeps, du kan gøre det vha cursors, men hvad præcis er det du gerne
>> vil? cursors er ret cpu-tung for et rdbms at håndtere
>
> Det kommer da bestemt an på, hvilket rdbms vi taler om. Jeg har aldrig
> hørt den påstand før. Min primære reference er Sybase og Ingres, og
> der har jeg aldrig hørt om problemer med cursors.

Har lige scannet Sybase's egen perfomance tuning guide
http://download.sybase.com/pdfdocs/srg1100e/sqlsrvpt.pdf
Her er tilsyneladende samme problemer som på MSSQL
Side 12-7: Comparing Performance With and Without Cursors

Der er en sammenligning mellem en update sp med set operationer (3 tables
scans) kontra brug af cursor iterativt med een table scan
Set operationen tager ca 2 min og den iterative cursor operation bruger ca 5
min

mvh/Peter Lykkegaard

---

Peter Lykkegaard wrote:
>
> Som svar på skriblerier forfattet af Kristian Damm Jensen
>
> > Peter Lykkegaard wrote:
>
> >> Jeps, du kan gøre det vha cursors, men hvad præcis er det du gerne
> >> vil? cursors er ret cpu-tung for et rdbms at håndtere
> >
> > Det kommer da bestemt an på, hvilket rdbms vi taler om. Jeg har aldrig
> > hørt den påstand før. Min primære reference er Sybase og Ingres, og
> > der har jeg aldrig hørt om problemer med cursors.
>
> Har lige scannet Sybase's egen perfomance tuning guide
> http://download.sybase.com/pdfdocs/srg1100e/sqlsrvpt.pdf
> Her er tilsyneladende samme problemer som på MSSQL
> Side 12-7: Comparing Performance With and Without Cursors
>
> Der er en sammenligning mellem en update sp med set operationer (3 tables
> scans) kontra brug af cursor iterativt med een table scan
> Set operationen tager ca 2 min og den iterative cursor operation bruger ca 5
> min.

En mark-up på en faktor 2,5 er bestemt et vægtigt argument (hvis man
havde brug for flere) for at holde sig fra cursors, hvor det kan lade
sig gøre.

Men det er ikke hvad jeg forestillede mig, da du skrev "cursors er ret
cpu-tung"; det gav mig nærmest det indtryk at vi talte om en faktor
10-20, minimum.



--
Kristian Damm Jensen | Feed the hungry at www.thehungersite.com
kristian-damm.jensen@cgey.com | Two wrongs doesn't make a right,
ICQ# 146728724 | but three lefts do.

---

Som svar på skriblerier nedfældet af Kristian Damm Jensen :

> Men det er ikke hvad jeg forestillede mig, da du skrev "cursors er ret
> cpu-tung"; det gav mig nærmest det indtryk at vi talte om en faktor
> 10-20, minimum.

Problemet er ikke så stort når man sidder og tester med en enkelt bruger
Men har man flere meget aktive brugere på databasen, der bruger en iterativ
type cursor operation så går det galt
Tablescans pga manglende index giver den samme effekt - eller måske værre?

Det er ret små servere hardwaremæssigt (single CPU og typisk uden RAID eller
evt 2 spejlede diske) jeg arbejder med
MSSQL er i princippet er temporært storage for data fra SAP i en meget kort
periode
Der er forholdsvis stor udskiftning af data over tid

mvh/Peter Lykkegaard

---

Kasper Kamp Simonsen skrev:

> Jeg har en stored procedure som tager et tal som input, nu
> kunne jeg godt tænke mig at kalde den stored procedure noget
> ala sådan her,

Se DECLARE CURSOR i BOL (onlinehjælpen).

--
Jens Gyldenkærne Clausen
MF (medlem af FIDUSO - www.fiduso.dk)
I ovenstående tekst benyttes nyt komma
(rettelser modtages gerne i dk.kultur.sprog)

---

Hej

Du kunne også lave en User Defined Function, så kunne du

select Funktion(tal) from table

Mvh
Carsten Schack-Eriksen