Query met First/Last en grouping

[patricw]

Beste allemaal,

Het volgende probleem kom ik niet uit:

2 tabellen met data en een query daarop met

Coatlijn 1 of 2
Specificatie A t/m G
Mass produktie run 1 t/m 16
Netto m2 (som van de m2 van de bijbehorende lotnummers)
Lotnummer

Ik groepeer op coatlijn, specificatie en mass produktie run, sommeer de netto m2 en wil daarbij de 1e en laatste rol (lotnummer).

En dat lukt niet; als ik in de query alleen het 1e lotnummer kies gaat het goed, dan krijg ik netjes coatlijn 2, specificatie A, massa produktie run 1 t/m 16 met 15000m2 en het 1e lotnummer. Wil ik vervolgens daarbij ook het laatste lotnummer dan krijg ik dezelfde lijst BEHALVE run 16.

Als ik de groepering uitzet staan uiteraard wel alle run's en lotnummers erin.

Hieronder de code:

SELECT [Twistar production data].Coatlijn, [Twistar production data].Specificatie, [Twistar lots].[Mass production run], Sum([Twistar lots].[net area (m2)]) AS [Netto m2], First([Twistar production data].Lotnummer) AS [Eerste rol], Last([Twistar production data].Lotnummer) AS [Laatste rol]
FROM [Twistar production data] INNER JOIN [Twistar lots] ON [Twistar production data].Lotnummer = [Twistar lots].[Twistar™ lot]
GROUP BY [Twistar production data].Coatlijn, [Twistar production data].Specificatie, [Twistar lots].[Mass production run]
HAVING ((([Twistar production data].Coatlijn)=[Forms]![Keuzescherm]![Coatlijn voor defects]) AND (([Twistar production data].Specificatie)=[Forms]![Keuzescherm]![Specificatie]) AND ((First([Twistar production data].Lotnummer)) Like "PR*") AND ((Last([Twistar production data].Lotnummer)) Like "PR*"))
ORDER BY [Twistar lots].[Mass production run], First([Twistar production data].Lotnummer);

Wat gaat hier mis?

Alvast dank voor reactie's.

Patric

 

[OctaFish]

Eerste en Laatste tegelijkertijd heeft alleen zin als je alleen groepeert op het veld waarvan er meer records zijn, zodat er een eerste en laatste waarde van Lotnummer is te scoren; je hebt nogal wat velden waarop je groepeert, en ik vermoed dat je daar wat velden uit moet halen om de goede groepering te maken.

 

[patricw]

Hoi Michel,

Hieronder een plaatje met het resultaat van de query:

Coatlijn Specificatie Mass production run Netto m2 Eerste rol aantal rollen
PCL2 830H240P15NHC 3 985 PRC4222W 8
PCL2 830H240P15NHC 4 909 PRC4921C 9
PCL2 830H240P15NHC 5 3590 PRD1521C 23
PCL2 830H240P15NHC 6 7446 PRD2821C 37
PCL2 830H240P15NHC 7 8492 PRD3722C 43
PCL2 830H240P15NHC 8 20019 PRD4325C 126
PCL2 830H240P15NHC 9 10493 PRE0121C 52
PCL2 830H240P15NHC 10 14440 PRE0622C 76
PCL2 830H240P15NHC 11 21361 PRE1921C 111
PCL2 830H240P15NHC 12 18887 PRE3721C 99
PCL2 830H240P15NHC 13 12606 PRE4724C 54
PCL2 830H240P15NHC 14 17220 PRF0323C 81
PCL2 830H240P15NHC 15 19192 PRF1123C 68
PCL2 830H240P15NHC 16 15384 PRF2225C 72

Nu heb ik alleen de eerste rol als criterium erbij, zodra ik een extra veld wil met laatste rol (zoals in bovenstaande code staat) verdwijnt de laatste regel totaal. Voor run 3 t/m/ 15 staat alles netjes erin zoals het hoort, dus bovenstaande tabel met als extra veld de laatste rol bij elke run.

Kan het met sortering of zo te maken hebben...first/last?

 

[OctaFish]

In je voorbeeldje komen [Coatlijn] en [Specificatie] herhaaldelijk voor, en kun je daar dus op groeperen, maar is [Mass production run] uniek. Elk nummer komt maar één keer voor; dan valt er dus weinig met First of Last te doen: First=Last namelijk.... En ook Gem, en Sum om alle rekenfuncties maar af te werken Je moet niet groeperen op unieke velden, want die beperken het resultaat tot één record.

 

[patricw]

Misschien dat ik de logica niet helemaal door heb (zou in mijn geval niet onlogisch zijn ) maar als ik ipv de specificatie in het vorige voorbeeld een andere neem gaat het wel goed. Want bij een unieke run horen meer dan 1 rol (b.v. 32 rollen) en daar kun je toch de first en last van nemen? Kijk maar hieronder, dezelfde code, andere specificatie:

Coatlijn Specificatie Mass production run Netto m2 Eerste rol Laatste rol
PCL2 950H180N45PHC 1 1053.82 PRD3121C PRD3721W
PCL2 950H180N45PHC 2 4231.82 PRD4121C PRD4226W
PCL2 950H180N45PHC 3 3690.42 PRD5025C PRD5125W
PCL2 950H180N45PHC 4 2273.78 PRE1322C PRE1327W
PCL2 950H180N45PHC 5 3041.74 PRE1621C PRE1627W
PCL2 950H180N45PHC 6 6280.03 PRE2524C PRE2626W
PCL2 950H180N45PHC 7 5366.15 PRE4331C PRE4522W
PCL2 950H180N45PHC 8 13127.11 PRF0824C PRF1028W
PCL2 950H180N45PHC 9 10606.1 PRF1727C PRF1929W

Dus eigenlijk vermoed ik dat er ergens in de data een "fout" zit maar die heb ik nog niet kunnen traceren.

Opgelost, maar ik begrijp het niet helemaal:

Onze lotnummers beginnen met PR, maar soms met SR als het proefrollen zijn. vandaar in de code het criterium bij lotnummer {Like PR*} omdat ik in de produktiegegevens geen SR-rollen wil. Nu zat er bij bovenstaand probleem een SR-rol in de reeks. En blijkbaar kon de code om welke reden dan ook (dat begrijp ik nog niet) hiermee niet overweg en werden alle rollen uit deze reeks weggelaten als ik de groepering deed. Ik heb nu de SR-rollen uit de tabel gegooid (waren er 2) en nu gaat het wel goed, zie hieronder:

Coatlijn Specificatie Mass production run Netto m2 Eerste rol Laatste rol
PCL2 830H240P15NHC 183.78 SRD3022C SRD5023W
PCL2 830H240P15NHC 3 985.992043 PRC4222W PRC4327W
PCL2 830H240P15NHC 4 909.022 PRC4921C PRC4929W
PCL2 830H240P15NHC 5 3590.844062 PRD1521C PRD1722W
PCL2 830H240P15NHC 6 7446.76 PRD2821C PRD3026W
PCL2 830H240P15NHC 7 8492.14 PRD3722C PRD4023W
PCL2 830H240P15NHC 8 20019.05 PRD4325C PRD5022W
PCL2 830H240P15NHC 9 10493.7 PRE0121C PRE0326W
PCL2 830H240P15NHC 10 14440.71 PRE0622C PRE1033W
PCL2 830H240P15NHC 11 21361.06 PRE1921C PRE2523W
PCL2 830H240P15NHC 12 18887.77 PRE3721C PRE4232W
PCL2 830H240P15NHC 13 12606.35 PRE4724C PRE5028W
PCL2 830H240P15NHC 14 17220.22 PRF0323C PRF0728W
PCL2 830H240P15NHC 15 19192.54 PRF1123C PRF1524W
PCL2 830H240P15NHC 16 15384.06 PRF2225C PRF2526W

De weggegooide rollen hadden lotnummer SRF2522C en SRF2522W, zaten dus midden in de reeks van run 16 qua produktietijd, maar qua sortering als laatste.

 

[patricw]

Na nog wat snuffelwerk vermoed ik dat het komt door het gebruik van de clause HAVING (wat de wizard automatisch doet) en je in dit geval beter WHERE kunt gebruiken.

Klopt dat?

 

[OctaFish]

MEt HAVING werken je functies op alle records uit je recordset, terwijl WHERE eerste de records uitfiltert, en daarna pas de functies er op los laat. Met HAVING zullen de 'stoorzenders' dus nog in de recordset zitten als je MIN en MAX gebruikt, en met WHERE zijn die er uitgehaald. Dus het maakt inderdaad uit of je WHERE of HAVING gebruikt. Ik was er nog niet aan toegekomen om die suggestie te doen, maar gelukkig heb je 'm zelf al gevonden
Maar dat is dus de reden dat we altijd aanbevelen om WHERE te gebruiken i.p.v. HAVING. Alleen zijn ze bij Microsof een beetje eigenwijs. En hebben ze geen kaas gegeten van databases....

 

[patricw]

Gelukkig jij wel (en ik een beetje).

Bedankt!

 

[Harry46]

Maar dat is dus de reden dat we altijd aanbevelen om WHERE te gebruiken i.p.v. HAVING

Dit is in zijn algemeenheid niet juist (nog afgezien van wie 'we' is).
HAVING moet in bepaalde gevallen gebruikt worden, nl. als de selectie na de groepering moet plaatsvinden

 

[patricw]

Dat is dus logisch , inherent aan de functie van HAVING

 

[OctaFish]

@Harry:

Dit is in zijn algemeenheid niet juist (nog afgezien van wie 'we' is)

Niet doen alsof ik de enige ben die de voorkeur geeft aan WHERE om te filteren.....dat riekt als persoonlijk natrappen. Bovendien wil je meestal wel degelijk filteren op de manier zoals ik heb beschreven.

HAVING moet in bepaalde gevallen gebruikt worden, nl. als de selectie na de groepering moet plaatsvinden

En daar ben ik het uiteraard wel mee eens: als het moet, dan moet het....

 

[Tardis]

Harry wijst je (volkomen terecht) op een onjuiste bewering van jouw kant.
Dat is geen natrappen, dat is een goed bedoelde opmerking van iemand die veel meer ervaren is op het vlak van MS Access dan jij.

Tardis

 

[OctaFish]

@Tardis:
Spuit 11 doet uiteraard ook een duit in het zakje... Geweldig om te lezen dat jij weet dat Harry meer ervaring heeft dan ik. Ik zal in de toekomst voor mijn spirituele zaken bij jou aankloppen, mijn vaste waarzegger kan zich bij deze als ontslagen beschouwen. Als je niks wezenlijks kunt bijdragen, hou dan lekker je mond...
Bovendien is mijn bewering niet onjuist, hooguit een beetje sterk uitgedrukt...

 

[patricw]

en ik had het topic zo mooi op opgelost gezet.

 

[OctaFish]

Er zijn een aantal lieden op het forum actief die je nog maar zelden ziet, maar die het prachtig vinden om met een grote pot zout achter mijn slakken aan te lopen... Enerzijds vervelend, anderzijds natuurlijk een groot compliment dat ze mij zo in de gaten houden Maar wat mij betreft was en is de topic echt wel dicht!

 

[patricw]

:thumb: waarvan akte!