tja,
har ett besynnerligt problem, någon som vet varför, jag har en helt vanligt t-sql cursor sats.
Kör jag enbart SQL satsen som fyller cursorn funkar den utmärkt

Men när jag kör hela harangen med fyllning av cursor och traversering av den då uppträder något märkligt fenomen.

Lite exempel kod
<code>
USE pubs
GO

-- Declare the variables to store the values returned by FETCH.
DECLARE @au_lname varchar(40), @au_fname varchar(20)
DECLARE @iCounter smallint


DECLARE authors_cursor CURSOR FOR
SELECT au_lname, au_fname FROM authors
WHERE au_lname LIKE "B%"
ORDER BY au_lname, au_fname

SET @iCounter = 1

OPEN authors_cursor

-- Perform the first fetch and store the values in variables.
-- Note: The variables are in the same order as the columns
-- in the SELECT statement.

FETCH NEXT FROM authors_cursor
INTO @au_lname, @au_fname

-- Check @@FETCH_STATUS to see if there are any more rows to fetch.
WHILE @@FETCH_STATUS = 0
BEGIN


-- Concatenate and display the current values in the variables.
PRINT "No: " + CAST(@iCounter AS varchar(3)) + " Author: " + @au_fname + " " + @au_lname

SET @iCounter = iCounter + 1

-- This is executed as long as the previous fetch succeeds.
FETCH NEXT FROM authors_cursor
INTO @au_lname, @au_fname
END

CLOSE authors_cursor
DEALLOCATE authors_cursor
GO
</code>

Och trots att SQL satsen som fyller cursorn fungerar utmärkt, får jag resultat som följer nedan:
<code>
No: 1 Author: Abraham Bennet
No: 2 Author: Reginald Blotchet-Halls
No: 3 Author: Abraham Bennet
No: 4 Author: Reginald Blotchet-Halls

No: 6 Author: Reginald Blotchet-Halls
No: 7 Author: Abraham Bennet
No: 8 Author: Reginald Blotchet-Halls

No: 10 Author: Abraham Bennet
No: 11 Author: Reginald Blotchet-Halls
No: 12 Author: Abraham Bennet
No: 13 Author: Reginald Blotchet-Halls
</code>

Den hoppar helt sonika över vissa!? Det står visserligen i dokumentationen att den gör endast aktuell while sats om den senaste FETCH INTO lyckades, men varför skulle den inte lyckas med det, eftersom SQL satsen till cursorn är ju rätt...

SNälla, någon som kan svara på varför det händer och vad man kan göra för att lösa det. Är det någon annan som råkat ut för det?

Jag vet nu varför den hoppar över vissa rader, enklare än vad man tror, som vanligt med andra ord.

Det kommer sig av att ett av printvärdena som jag försöker skriva ut är null varför den helt sonika struntar att skriva ut något alls för den raden.

Först trodde jag det var så illa att fetch kommandot misslyckades med en inläsning, men det kunde lätt kontrolleras genom att skriva ut variabeln @@FETCH_STATUS direkt efter FETCH INTO satsen, den ska visa 0 om det gick bra att läsa in nästa post till variablerna, annars får man ett värde mindre än 0 (-1 elr -2)

> Det kommer sig av att ett av printvärdena som jag försöker skriva ut är null varför den helt sonika struntar att skriva ut något alls för den raden.

Nja, den struntar inte i att skriva ut (därav de tomma raderna), det är bara det att den skriver bara ut ingenting. NULL konkatenerat med något blir NULL.

Varför använder du en cursor? Jag antar att den egentligen gör mer än vad du visar här, att detta bara var någon exempelkod eller något. Annars förstås jag inte alls varför du använder en cursor.

ah ok, gammal hederlig matematik, null * something= null, nice...

Jodå, den gör lite mer än exemplet, den tar reda på en lista av felaktiga adresser och sedan beroende på vissa variabler så räknar den fram värden som sedan matas in dbn via ett par andra storeprocedures... men scriptet var för bökigt att ta med här så jag klippte hjälpens exempel och modifierade det lite för att beskriva mitt problem.

Att använda cursor modellen är ofta för mig ett lätt sätt att hantera lite mer komplicerade uppgifter (itereringar är mycket trevliga), försöker dock lära mig mer SQL, och förvånas hela tiden hur mycket som går att åstadkomma i språket, mitt nästa bokinköp ska bli Joe Celkos grymma tips och tricks bok, kanske man då kan nå gurustadiet, hehe (skämt åsido).

> ah ok, gammal hederlig matematik, null * something= null, nice...

Ja, matematik vet jag inte, ett okänt värde som på något vis kombineras med ett känt värde måste ju resultera i ett okänt värde. Dock ej samma okända värde som man började med, även om det skulle kunna vara det.. hmm nu blir det lulligt. :)
Fast det är ju förstås matematik... Menade mest att det inte är på så särskilt hög nivå.

> Jodå, den gör lite mer än exemplet, den tar reda på en lista av felaktiga adresser och sedan beroende på vissa variabler så räknar den fram värden som sedan matas in dbn via ett par andra storeprocedures... men scriptet var för bökigt att ta med här så jag klippte hjälpens exempel och modifierade det lite för att beskriva mitt problem.

Nja, jag är fortfarande tveksam till varför en cursor ska användas. Kolla bl a Evil T-SQL och Evil T-SQL II på sql.nu (http://www.sql.nu/).

> Att använda cursor modellen är ofta för mig ett lätt sätt att hantera lite mer komplicerade uppgifter (itereringar är mycket trevliga)

Nej, jag tycker precis tvärtom. Itereringar är något programmerare vana vid procedurell programmering har med sig när de ska använda databaser, istället för att använda mängdbaserad logik i SQL.

> mitt nästa bokinköp ska bli Joe Celkos grymma tips och tricks bok

Inte säker på vilken av hans böcker du menar, men jag rekommenderar SQL for Smarties, det är den mest användbara av hans böcker.

Jo det förstås, det kan mycket väl stämma i mitt fall, har en TURBO Pascal bakgrund och mycket mer procedurell programmering än så blir det nog inte, även om Object Pascal faktiskt var nog så objektorienterad på sin tid... men databaser och mängder.... mmm det är lite annorlunda, varför man ibland fastnar i vinkelvolten och gör logiska dubbelknutar!?

Och då kommer den gamle hederlige proceduren fram, steg för steg, enkelt och snyggt uppställt... prestanda och coolhets faktorer står då väldigt lågt i kurs hehe