[.NET] onverwachte resultaten bij uitvoeren query met OleDb

[whoami]

Ik heb volgende query:

code:

SELECT tblCategory.CategoryId, tblCategory.Name, 
             ( SELECT SUM (tblCashflow.Amount) 
               FROM tblCashflow
               WHERE tblCashflow.CategoryId = tblCategory.CategoryId
                    AND tblCashflow.TypeId = 1 
                    AND tblCashflow.TransactionDate >= @p_aBeginDate
                    AND tblCashflow.TransactionDate < @p_aEndDate ) AS a,
             ( SELECT SUM (tblCashflow.Amount) 
               FROM tblCashflow
               WHERE tblCashflow.CategoryId = tblCategory.CategoryId
                    AND tblCashflow.TypeId = 2 
                    AND tblCashflow.TransactionDate >= @p_bBeginDate
                    AND tblCashflow.TransactionDate < @p_bEndDate ) AS b,
FROM tblCategory

Als ik deze query uitvoer in m'n .NET applicatie op een SQL Server databank, met behulp van de SqlClient classes, dan krijg ik de verwachte resultaten.
Voer ik deze query echter uit in een .NET applicatie op een Access DB (met de OleDb classes), dan krijg ik foute resultaten.

Ik voer de query uit en loop met een OleDbDataReader over de resultaten, en vul een custom collectie met de resultaten van de query.
Het veld-type van tblCashflow.Amount is een decimal (zowel in sql server als in access). De data-reader leest dit als volgt uit:

code:

decimal a = Convert.ToDecimal (dr[2]);

Mbhv de SqlClient krijg ik de juiste resultaten, met de OleDb classes krijg ik in bepaalde gevallen een 0 terug, en in andere gevallen 241.900 (ook dat is fout) terug.

Het vreemde is dat, als ik die query direct uitvoer in Access, ik wel de juiste resultaten terugkrijg. Ik denk dus dat het probleem ergens bij de OleDb classes moet liggen, maar ik zie niet direct hoe ik daaromheen kan werken.

[gorgi_19]

Een pure gok, maar ondersteunde OleDB niet de named parameters?

[pjonk]

gorgi_19 schreef op zondag 08 januari 2006 @ 10:23:
Een pure gok, maar ondersteunde OleDB niet de named parameters?

In zoverre dat je de parameters moet toevoegen in dezelfde volgorde als dat ze in de query staan. De @ notatie is voor de rest hetzelfde bij OleDb.

[whoami]

gorgi_19 schreef op zondag 08 januari 2006 @ 10:23:
Een pure gok, maar ondersteunde OleDB niet de named parameters?

OleDb ondersteund idd niet named parameters, maar in dit geval zou het gewoon moeten werken, aangezien ik m'n parameters in de juiste volgorde aan m'n param-collectie toevoeg zoals ze in m'n query verschijnen.
Ik heb trouwens ook een aantal andere queries die zo goed werken.

[pjonk]

Is het getal dat je terugkrijgt van de DataReader (dus voor de conversie Convert.ToDecimal) ook al verkeerd? Misschien dat er iets fout gaat bij de conversie naar een System.Decimal.

[whoami]

pjonk schreef op zondag 08 januari 2006 @ 11:22:
Is het getal dat je terugkrijgt van de DataReader (dus voor de conversie Convert.ToDecimal) ook al verkeerd? Misschien dat er iets fout gaat bij de conversie naar een System.Decimal.

Daar heb ik ook in eerste instantie aan gedacht, als ik echter dit doe:

code:

Console.WriteLine (dr[2].ToString());

dan krijg ik ook verkeerde resultaten terug. Het zit 'm dus niet bij de conversie naar de decimal.

[pjonk]

Misschien dat je een rip van je database met die tabel met wat test data online kunt zetten. Dan kan ik hier wel even voor je testen.

Edit:
Ik zie dat je @p_aBeginDate en @p_aEndDate 2 keer voorkomen. Voeg je de parameters aan je Command ook dubbel toe?
Oeps niet goed gelezen. Ik zie nu dat je 4 verschillende parameters hebt: @p_aBeginDate, @p_aEndDate, @p_bBeginDate, @p_bEndDate
Ben nu ffies weg rond een uurtje of 1 kan er wel naar kijken.

[ Voor 62% gewijzigd door pjonk op 08-01-2006 11:35 ]

[EfBe]

Ah, deze error heb ik ook gehad ooit.

De volgorde waarin je je parameters definieert is bij access belangrijk. De parameters in a subquery moeten EERST worden genoemd, daarna de parameters in de rest. Dit is voor je values belangrijk, dus je moet de waardes voor de nested parameters eerst noemen, daarna de values voor de andere parameters. Geen idee of dat in dit geval iets uitmaakt. In het geval waarbij 2 parameters dus verwisseld worden door access krijg je geen error wanneer beide van hetzelfde type zijn, en je dus je de blubber zoekt waarom het toch in vredesnaam fout gaat.

Bv als je doet:
update table
set field = @value
where
(
-- complexe select met parameters
)

dan moet je dus EERST die parameters in die where subquery specificeren en daarna pas @value!

[ Voor 15% gewijzigd door EfBe op 08-01-2006 11:45 ]

[whoami]

Ik heb enkel parameters bij m'n subqueries. Die parameters worden goed aan m'n collectie toegevoegd.

Ik heb het probleem ondertussen opgelost. Na enig onderzoek bleek dat hij de mist inging als m'n resultaat niet NULL was. Blijkbaar ging er iets fout in m'n SUM().
Ik heb die dus ff zo herschreven:

code:

SELECT bla,
             ( SELECT SUM( IIF(tblCashflow.Amount IS NULL, 0, tblCashflow.Amount) ) 
             ....

Iig thx voor het meedenken.

EfBe schreef op zondag 08 januari 2006 @ 11:43:
De volgorde waarin je je parameters definieert is bij access belangrijk. De parameters in a subquery moeten EERST worden genoemd, daarna de parameters in de rest. Dit is voor je values belangrijk, dus je moet de waardes voor de nested parameters eerst noemen, daarna de values voor de andere parameters. Geen idee of dat in dit geval iets uitmaakt. In het geval waarbij 2 parameters dus verwisseld worden door access krijg je geen error wanneer beide van hetzelfde type zijn, en je dus je de blubber zoekt waarom het toch in vredesnaam fout gaat.

Bv als je doet:
update table
set field = @value
where
(
-- complexe select met parameters
)

dan moet je dus EERST die parameters in die where subquery specificeren en daarna pas @value!

Ook bedankt voor deze tip. (Niet dat ik nu zo'n geval heb), maar, normaal zou je idd denken dat je eerst die @value moet toevoegen, aangezien die als eerste in je query voorkomt.
Maar, aangezien een subquery eerst uitgevoerd wordt, is het wel logisch dat je idd eerst de subquery params moet toevoegen.
Ik kan me echter wel voorstellen dat je in zo'n geval best ff gefrustreerd kunt zoeken in zo'n situatie.

[ Voor 62% gewijzigd door whoami op 08-01-2006 11:56 ]

[EfBe]

whoami schreef op zondag 08 januari 2006 @ 11:51:
[...]
Ook bedankt voor deze tip. (Niet dat ik nu zo'n geval heb), maar, normaal zou je idd denken dat je eerst die @value moet toevoegen, aangezien die als eerste in je query voorkomt.
Maar, aangezien een subquery eerst uitgevoerd wordt, is het wel logisch dat je idd eerst de subquery params moet toevoegen.
Ik kan me echter wel voorstellen dat je in zo'n geval best ff gefrustreerd kunt zoeken in zo'n situatie.

Ja dat kostte wel even tijd, ik wist niet zeker of dit hetzelfde geval was, maar indien wel, dan had je er wellicht wat aan gehad .