Archief - SQL count

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

Piecemaker

Legacy Member
kheb een probleempje met een query.

Ik heb in mn DB de volgende tabellen:

Rekeningen (RekeningID, Datum)
Behandelingen_Rekeningen (RekeningID, BehandelingID, Prijs)
Behandelingen (BehandelingID, Behandelingnaam, .....)

In mijn functie geef ik jaar en datum mee als parameters en dan zou die functie alle behandelingen moeten teruggeven met hun bijhorende prijs.

Dit is mijn functie tot hier toe:

Code:
Public Shared Function test(ByVal maand As Integer, ByVal jaar As Integer) As SqlDataReader

        Dim con As SqlConnection
        Dim cmd As SqlCommand

        Try
            con = New SqlConnection(My.Settings.bellezaDBConnectionString)
            cmd = New SqlCommand("SELECT Behandelingen.Behandelingnaam, Behandelingen_Rekeningen.Prijs " & _
                                 "FROM Behandelingen, Rekeningen, Behandelingen_Rekeningen " & _
                                 "WHERE Rekeningen.RekeningID=Behandelingen_Rekeningen.RekeningID AND " & _
                                 "Behandelingen_Rekeningen.BehandelingID=Behandelingen.BehandelingID AND " & _
                                 "MONTH (Rekeningen.Datum) = @maand AND " & _
                                 "YEAR (Rekeningen.Datum) = @jaar " & _
                                 "ORDER BY Behandelingen.Behandelingnaam", con)

            cmd.Parameters.Add(New SqlParameter("@maand", maand))
            cmd.Parameters.Add(New SqlParameter("@jaar", jaar))

            con.Open()

            Return cmd.ExecuteReader(CommandBehavior.CloseConnection)

        Catch ex As Exception
            MessageBox.Show(ex.Message)
            Return Nothing
        End Try
    End Function

En dit krijg ik nu als uitvoer:

behandeling1 5 €
behandeling1 5 €
behandeling1 7 €
behandeling2 12 €
behandeling2 14€
behandeling2 14€
behandeling2 14€
.....

Nu wil daar het volgende van maken:

2 x behandeling1 5 €
1 x behandeling1 7 €
1 x behandeling2 12 €
3 x behandeling2 14 €

Ik heb al vanalles geprobeerd met een count maar ik krijg het niet voor mekaar.

Ik kan dit natuurlijk gewoon in de uitvoer aanpassen, maar ik zou dit liever direct al in de query doen.

Piecemaker

Legacy Member
al geprobeerd, ik heb gewoon ORDER BY Behandelingen.Behandelingnaam vervangen door GROUP BY Behandelingen.Behandelingnaam, Behandelingen_Rekeningen.Prijs.

Dan krijg ik als uitvoer:

behandeling1 5 €
behandeling1 7 €
behandeling2 12 €
behandeling2 14 €

hoe krijg ik hier dan nog de aantallen bij??

Kemblin

Legacy Member
awel da is het toch bijna, dan moet ge natuurlijk nog ne count(*) doen eh bij uwe select

Piecemaker

Legacy Member
ja da weetk ook wel, ma hoe doe ik die count daar juist op?

Kemblin

Legacy Member
owkay, mss uw vraag iets duidelijker stellen? tis ne count(*) zoals ik hierboven al zei

Tomba

Legacy Member
SELECT Behandelingen.Behandelingnaam, Behandelingen_Rekeningen.Prijs , count(Behandelingen.Behandelingnaam)
FROM Behandelingen, Rekeningen, Behandelingen_Rekeningen
WHERE Rekeningen.RekeningID=Behandelingen_Rekeningen.RekeningID
AND Behandelingen_Rekeningen.BehandelingID=Behandelingen.BehandelingID
AND MONTH (Rekeningen.Datum) = @maand AND
YEAR (Rekeningen.Datum) = @jaar
GROUP BY Behandelingen.Behandelingnaam, Behandelingen_Rekeningen.Prijs

GROUP BY groepeert alle gelijke gegevens samen
door ook een count van (eender welk) van die gegevens op te vragen, krijg je ook het aantal keren dat hij dit gegeven gegroepeerd heeft

Kemblin

Legacy Member
alright das wat ik al 2x zei, swat nu moet hij dus enkel nog maar copy pasten...

stelly

Legacy Member
Probeer die try nog iets in te perken. Normaal heb je die enkel op je .Open() nodig.

Obliv`

Legacy Member
T0mBa zei:
Een try hoort rond àlle code die fouten kan geven

Een try/catch schrijf je als je de fout ook werkelijk gaat afhandelen of wanneer je ze proper aan je gebruiker wil laten zien.

De meeste exception handler gebeurt in de UI en controller laag, als mijn data access laag een exception gaat throwen omdat hij niet naar de database kan connecteren ga ik echt geen exception handling doen op die plek hoor, want je kan de fout daar toch niet oplossen. Ik laat gewoon de error doorvloeien naar de controller, die ze dan wel zal opvangen en ofwel de fout tonen aan de gebruiker of de gebruiker vragen om een bepaalde actie te ondernemen om de fout recht te zetten.

stelly

Legacy Member
T0mBa zei:
Een try hoort rond àlle code die fouten kan geven
con = ...
cmd = ...
Da moet al zeker niet in een try zitten. Als ge iets in uw settings hebt opgeslaan moet ge zeker zijn dat het er juist stond.

cmd.Parameters.Add(New SqlParameter("@maand", maand))
cmd.Parameters.Add(New SqlParameter("@jaar", jaar))
Testen of parameters correct zijn ingevoerd doet ge niet met een tryblok. Hier kunt ge ne simpele int.TryParse doen, voor zwaarder werk neemt ge gewoon Regex erbij.

Bubbling Zombie

Legacy Member
T0mBa zei:
Een try hoort rond àlle code die fouten kan geven

Redeneringen zoals die zorgen voor lege catch blokken en debugging die meer tijd in beslag neemt als nodig :)

Obliv`

Legacy Member
Bubbling Zombie zei:
Redeneringen zoals die zorgen voor lege catch blokken en debugging die meer tijd in beslag neemt als nodig :)

CTRL + ALT + E en dan 'break on any CLR exception' aanvinken, is wel handig als je van die baggercode moet debuggen ;).

Bubbling Zombie

Legacy Member
Obliv` zei:
CTRL + ALT + E en dan 'break on any CLR exception' aanvinken, is wel handig als je van die baggercode moet debuggen ;).

juh. Maar die bugreport zou anders zijn, "ik krijg hier een fout" en dan nen attachment me de stacktrace. Anders (met de try catches) ist "'t werkt nie". En dan kunde beginnen zoeken é.

stelly

Legacy Member
Tja debugging is om fouten te vinden. Try/catch is om fouten op te vangen die ge niet kunt voorzien en ze eventueel te herstellen. In deze code gewoon slechte manier van werken.

Obliv`

Legacy Member
Bubbling Zombie zei:
juh. Maar die bugreport zou anders zijn, "ik krijg hier een fout" en dan nen attachment me de stacktrace. Anders (met de try catches) ist "'t werkt nie". En dan kunde beginnen zoeken é.

Volgens mij is de stacktrace op dat moment nog wel correct hoor, als je breakt op eender welke exception.

Je komt natuurlijk ook soms dingen als dit tegen (ook wel 'breaking the stack' genaamd):
Code:
catch(Exception ex)
{
throw ex;
}

Die throw ex gaat de informatie die de onderliggende methods in de stacktrace hebben gezet clearen en doen alsof de exception gebeurd is in de method zelf.

In sommige gevallen is dat natuurlijk gewenst, maar meestal ben je beter af met dit:
Code:
catch(Exception ex)
{
throw;
}

Of dit (wat eigelijk hetzelfde doet):
Code:
catch(Exception ex)
{
throw new Exception(ex);
}
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan