[SQL Server] dynamische query bij gebruik cursor

[Verwijderd]

Is het mogelijk (en zo ja hoe) om een dynamiasche query te gebruiken bij het openen van een cursor ?

b.v.
DECLARE @Member varchar(50)
DECLARE Subscribers SCROLL CURSOR FOR
--- QUERY WAARBIJ WHERE CLAUSE TELKENS ANDERS IS ---
OPEN Subscribers
FETCH NEXT FROM Subscribers INTO @Member
IF @@FETCH_STATUS = 0
BEGIN
WHILE @@FETCH_STATUS = 0
BEGIN
--- ACTIE ---
FETCH NEXT FROM Subscribers INTO @Member
END
END
ELSE
GOTO error
CLOSE Subscribers
DEALLOCATE Subscribers


Bedankt.

[raptorix]

ja dat is mogelijk

[Crazy D]

Hoe anders is "telkens anders"?
Je kan voor je cursor-query bij mijn weten gewoon een normale query gebruiken, iets als SELECT blah FROM Tabel WHERE ID = @id (er vanuit gaande dat @id als parameter aan de stored procedure wordt meegegeven).

LOL@raptorix

[Verwijderd]

telkens anders is erg anders.
niet alleen de where clause kan anders zijn ook de from clause

een variabele veranderen zoals in je voorbeeld kan inderdaad op die manier.

b.v.
SELECT MemberID FROM Subscribers WHERE ServiceID=12
of
SELECT Subscribers.MemberID FROM Subscribers INNER JOIN Countries ON Subscribers.CountryID = Countries.CountryID WHERE Country = "NEDERLAND" AND ServiceID=12

[raptorix]

De truc is dat je de hele boel als een string opbouwt en dan execute, kijk uit met overdadig gebruik van cursors, hoewel je er soms niet onderuit komt is het in veel gevallen te omzeilen.

[Crazy D]

Op donderdag 04 april 2002 12:24 schreef raptorix het volgende:
De truc is dat je de hele boel als een string opbouwt en dan execute, kijk uit met overdadig gebruik van cursors, hoewel je er soms niet onderuit komt is het in veel gevallen te omzeilen.

Met sp_executesql (toch?) kun je idd leuk die dynamische queries opbouwen en executen, maar kun je het resultaat daarvan ook in een cursor stoppen? (of een willekeurige stored proc).

[Verwijderd]

Op donderdag 04 april 2002 13:15 schreef Crazy_D het volgende:

[..]

Met sp_executesql (toch?) kun je idd leuk die dynamische queries opbouwen en executen, maar kun je het resultaat daarvan ook in een cursor stoppen? (of een willekeurige stored proc).

Men opene books online, kijkt bij DECLARE cursor en ziet:

code:

Transact-SQL Extended Syntax
DECLARE cursor_name CURSOR 
[ LOCAL | GLOBAL ] 
[ FORWARD_ONLY | SCROLL ] 
[ STATIC | KEYSET | DYNAMIC | FAST_FORWARD ] 
[ READ_ONLY | SCROLL_LOCKS | OPTIMISTIC ] 
[ TYPE_WARNING ] 
FOR select_statement 
[ FOR UPDATE [ OF column_name [ ,...n ] ] ]

en bij 'select_statement':

Is a standard SELECT statement that defines the result set of the cursor. The keywords COMPUTE, COMPUTE BY, FOR BROWSE, and INTO are not allowed within select_statement of a cursor declaration.

Het lijkt me dus niet dat je daar een exec van een stored proc kunt plaatsen.

Dit lijkt een ramp, maar hoeft helemaal niet. Als je nl. nadenkt over wat een cursor doet, dan kun je het simuleren. Een cursor maakt nl. een temptable aan en gaat daarin rows fetchen. Je kunt dus zelf een temptable vullen met de results van je EXEC sp_executesql @sSQLCommand en DAAR verdere logica op los laten.

Ik weet niet waarom je de dynamische sqlstring + cursor nodig hebt, wellicht zijn er veel betere (en efficientere) oplossingen mogelijk. Kun je een tipje van de sluier oplichten?

[Crazy D]

Op donderdag 04 april 2002 13:31 schreef Otis het volgende:
Men opene books online, kijkt bij DECLARE cursor en ziet:
[knip]

Ah gelukkig ik begon al een beetje aan m'n begrijpend lezen te twijfelen...

Maar ik ben ook wel benieuwd waarom de query zo dynamisch moet zijn.

[Verwijderd]

De toepassing is als volgt:

In een tabel Batches wordt een record geinsert met als 1 van de kolommen een SQL statement.

Dit SQL statement is gegenereerd aan de hand van een profiel selectie door een gebruiker van een website (b.v. selecteer alle leden met als kenmerk: geslacht=man, leeftijd tussen 20 en 25, woonachtig in Noord-Brabant)

Naar de leden die aan dit profiel voldoen moet een SMSje gestuurd worden.
Het SMS systeem werkt met een tabel waarin per te verzenden smsje een record aanwezig is met o.a. het gsmnummer en de tekst.

Nu wil ik bij het inserten van een record in de tabel Batches een Trigger uitvoeren, waarbij het SQL statement wordt uitgevoerd en er per lid een record in de tabel voor het SMS systeem komt.

Dus dacht ik: in de trigger het SQL statement in een cursor gooien, deze doorlopen en per gevonden lid een record in de tabel van het SMS systeem gooien.

Nu zul je zeggen: waarom gooi je niet direct die records in het SMS systeem ? Simpele verklaring: daar moet de websitegebruiker te lang op wachten (soms wel 10000 records)

De communicatie tussen de website en SQL Server (2000) loopt overigens via ASP.

Wie heeft een oplossing of misschien een beter alternatief ??

[Crazy D]

Kun je niet een job aanmaken die ieder uur (oid) kijkt of er iets in die tabel staat en zo ja de SMS tabel vult?

[Verwijderd]

Een job is geen optie, aangezien de smsjes direct verzonden moeten kunnen worden (gebruiker kan dat beinvloeden door een datum en tijd mee te geven)

Hoe zou je overigens het probleem oplossen als je een job gebruikt, ben je dan ook niet gebonden aan stored procedures en dus het cursor probleem ?

[Verwijderd]

Microsoft raadt het af cursors in triggers te gebruiken. Daar zijn ze ook niet voor bedoeld (triggers).

Ik begrijp verder uit je verhaal dat je een profiel hebt in de vorm van een sqlstatement. Zodra er 1 insert plaatsvindt in 'batches' wordt naar ieder 'lid' van het profiel van het geinserte record een sms gestuurd, begrijp ik het zo goed?

Indien niet, don't blame me, ik begrijp werkelijk niet wat je wilt. Als tip: profielen zijn datasets. Je gaat geen queries opslaan, _NOOIT_. Je slaat parameters op voor queries. Dus de parametes van een profiel. Die geef je mee aan een profiel-selectie stored proc en die levert de rows op van leden die beantwoorden aan dat profiel. Die insert je dan in een table waar een batch job rows uit haalt voor verdere verwerking BUITEN de database.

Dat je het niet anders doet omdat je anders moet wachten, zie ik niet: als je dan moet wachten, waarom nu niet?