Gegevenstype verandert in een tweede query

[jhdw]

Goedemiddag,

Ik heb een vreemd probleem.
In de ene query (afb. qry_130) kan ik op het pijltje bij 130_Procent klikken en dan verschijnt er een lijst met alle waardes. Dat geldt voor alle velden. In de bron is het een numeriek veld, dubbele precisie.
Het 130_Procent is het resultaat van de som van 2 andere numerieke velden, 130_Procent: Nz([a130_Procent];0)+Nz([b130_Procent];0)

In de tweede query (afb. qry_130_1 en 2) is deze query gekoppeld aan een tabel, met nog een andere query). Alleen in het veld 130Uren (is hetzelfde veld als hierboven, alleen een andere veldnaam) kan ik geen lijst met waardes zien(qry_130_1). In de andere velden kan dat wel, zie qry_130_2.

Een voorbeeld maken wordt nog lastig.

Misschien heeft iemand een idee wat hier fout gaat.

Alvast bedankt

Gr. Jan

 

[AccessGuru]

Tja, zonder voorbeeldje kan ik er toch bar weinig van maken. En ik sta niet te popelen om eerst een vergelijkbaar voorbeeldje te maken. Da's toch iets dat jíj mag doen . Kwestie van gelijk oversteken: jij steekt tijd in het maken van een voorbeeldje, wij steken tijd in het zoeken naar de oorzaak.

 

[NoellaG]

Een mogelijke oplossing kan je vinden op https://stackoverflow.com/questions/10880994/access-filter-wont-show-value-list-to-choose-from-after-1st-filter-is-set/10949856#10949856

 

[jhdw]

ik heb een voorbeeld gemaakt.
In de query 10_SELECTIE_2 bij het veld 130_Procent zit het probleem. In dit veld zie ik geen lijst met waardes, in de andere velden wel.
Als je van deze query een tabelmaakquery maakt, dan zie je in hetzelfde wel een lijst met waardes.

Hopelijk is het duidelijk wat mijn probleem is.

Alvast bedankt voor de moeite

Gr. Jan

 

[NoellaG]

Waarschijnlijk worden de berekeningen zo complex dat je tegen de limieten aanloopt van wat access kan.
Een oplossing kan zijn: al een basis van de berekeningen maken in de tabellen: dat is de reden dat berekende velden in een tabel bestaan. Een andere reden voor berekende velden in een tabel is dat dit de enige mogelijkheid is om een index aan te maken op een berekend veld.
Andere mogelijkheid: de zwaarste berekeningen uit je query halen en een VBA functie ervoor schrijven.

 

[AccessGuru]

De opmerkingen van noella m.b.t. berekende velden laat ik voor haar rekening; blijkbaar heeft ze nog nooit een database tot in 3NF genormaliseerd, want dan zou ze dat niet zeggen. In mijn optiek (en ik sta daar denk ik niet alleen in) gebruik je een tabel om pure gegevens in op te slaan. Gegevens die niet afhankelijk zijn van andere gegevens in dat record.

Indexeren op getallen lijkt mij sowieso een nutteloze bezigheid, maar dat kan met mijn vakgebied te maken hebben. Dan nog zou ik nooit indexeren op een berekend veld. Daarnaast heb je nooit een berekend veld nodig in een database tabel; elke waarde die je op die manier zou willen opslaan kun je ook (en veel beter) berekenen op het formulier waarmee die waarde gegenereerd wordt. Bij een factuur bijvoorbeeld heb je bestelde artikelen en een artikelprijs. De prijs is variabel, maar op de factuur mag die niet veranderen. Dan sla je dus in de tabel de actuele prijs op, en eventueel ook de totaalprijs van [Aantal]*[Prijs]. De dataredundantie die dat oplevert is te rechtvaardigen doordat je gefixeerde gegevens nodig hebt. Die zijn alleen te wijzigen door in de tabel zelf aan te passen, wat uiteraard voorkomen moet worden. Wat je niet wilt, is dat een berekend veld de gegevens vervolgens alsnog kan wijzigen, bijvoorbeeld doordat iemand het aantal artikelen verhoogt of verlaagt, zodat de prijs óók word aangepast. Daarnaast gooi je met berekende velden alle compatibiliteit met andere systemen gelijk uit het raam. Kortom: ik heb ze nooit nodig gehad, en ga ze ook zeker nooit gebruiken.

Wat je eigenlijke vraag betreft: ik vraag met af of het probleem wordt veroorzaakt doordat je tegen de limieten van Access aanloopt. Wél vind ik dat je een nodeloos ingewikkelde brij van aan en in elkaar geknoopte queries gebruikt. Ik heb er een half uurtje naar gekeken (is veel te weinig gezien de complexe manier waarop je e.e.a. in elkaar hebt gezet) en constateer dat je continue queries in queries aan het oproepen bent. Dat is vragen om moeilijkheden. Dat kan echt simpeler. Neem als voorbeeldje de query "qry_tbl_tijden_A". Die is niet gebaseerd op een tabel, maar op een andere query: "qry_tbl_tijden". Nergens voor nodig; het gewenste resultaat kun je in één query maken:

SELECT Code_Mont_Dag, Sum(Travel_time) AS Travel_time, Sum(Labour_time) AS Labour_time, Sum(Departure_time) AS Departure_time, 
IIf([Travel_time]>0 Or [Departure_time]>0,[Travel_time]+[Departure_time],0) AS ReisTijd, [Travel_time]+[Departure_time]+[Labour_time] AS BrutoTijd
FROM tbl_tijden
GROUP BY Code_Mont_Dag, Technician, W_Date, Ongewijzigd
HAVING Ongewijzigd=True;

Mij ontbreekt de lust/energie (ik word al moe als ik naar de constructies kijk) om de rest op te knappen, maar ik zou eerst eens wat minder queries gebruiken en proberen om alles zoveel mogelijk op basis van tabellen te bereiken, en niet steeds eerst een query met berekening er tussen te hangen.

 

[NoellaG]

Daarnaast gooi je met berekende velden alle compatibiliteit met andere systemen gelijk uit het raam.

Berekende velden zijn net in Access opgenomen om compatibel te zijn met sql server en andere database sytemen

Indexeren op getallen lijkt mij sowieso een nutteloze bezigheid

Numlerieke velden zijn de beste velden om te indexeren (zoals ook automatisch gebeurt als je een autonumber als primary key gebruikt.

Daarnaast heb je nooit een berekend veld nodig in een database tabel

enkele redenen:
* als je dezelfde berekening in verschillende queries (of in de applicatie: forms en reports) moet maken
* als je in een query een criterium op een berekend veld moet zetten: het berekend veld zorgt ervoor dat de query niet een full scan moet doen en de berekening in elke regel moet maken
* als je een index op een berekend veld nodig hebt: zie vorige opmerking
* als de berekeningen in de query te complex worden om te evalueren kan je de basis berekening al in de tabel laten gebeuren

Je moet niet te pas en onpas berekende velden gebruiken, maar bij juist gebruik kunnen ze je database serieus verbeteren. En als de database sneller gaat, dan ook de applicatie die daarboven draait.