Sorteren in een formulier op meerdere velden

[AccessDude]

Beste forumgebruikers

Eerste en vooral zou ik jullie willen bedanken voor het spoedige antwoord dat ik altijd krijg op mijn vragen. Ik ben hierdoor al een heel stuk verder geraakt. :thumb:

Verder zit ik met nog een vraag. Je kan in een formulier sorteren in het eigenschappenvenster. Dit kan echter maar op 1 veld denk ik. Is er een manier om op 2 of meerdere velden te sorteren in een formulier? Mijn redenering is een query maken, daarin sorteren, en hierin dan een formulier maken. Maar misschien zoek ik het hiermee te ver?

Alvast bedankt!

 

[OctaFish]

Sorteren doe je het beste in de onderliggende query, waarin je elk veld naar behoeven oplopend of aflopend kunt sorteren. Dat kan ook in een formulier, maar dan luistert de syntax veel nauwer. Vandaar de aanbeveling om het in de query te doen.

 

[AccessDude]

Misschien een domme vraag, maar als je een berekend veld hebt, dan mag je dat ook al in je query opnemen zeker? En als je later gegevens toevoegt aan je tabel, dan wordt de query en het formulier ook aangepast zeker?

 

[OctaFish]

Een berekend veld? Waarom heb je dat nodig? Ik maak berekeningen altijd in de query. Heb echt nog nooit een berekend veld nodig gehad... Ben ik dan zo slim, of is Microsoft zo dom?

 

[AccessDude]

In mijn cursus noemen ze het toch een berekend veld. Bijvoorbeeld als je verkoopprijs met BTW wil berekenen.

Verkoopprijs incl BTW: [Verkoopprijs]*(1+([BTWpercentage]/100))

 

[JohanRVT]

Je kunt in een formulier een subformulier maken dat je dan met een X aantal keuzelijsten, keuzerondjes of vinkjes gecombineerd kan filteren. Iedere waarde uit de keuzelijst, etc... wordt dan gebruikt om de query op te bouwen voor je subform waarbij je dan desgewenst kolommen kunt verbergen, sorteren, etc.... De formulierfilter verschijnt in een apart veldje en je kunt een rapport maken gebaseerd op de zelfde query. Vraag wel een beetje VBA, maar eens het goed in elkaar zit kun je er als gebruiker enorm veel mee doen. Zie voorbeeldje voor ons wachtlijstbeheer in het WZC
Natuurlijk kun je in die query een berekend veld opnemen, dat maakt niets uit.

 

[OctaFish]

De spraakverwarring neemt toe . Ik denk dat TS inderdaad al een berekening maakt in de query (wat prima is) en het niet over een berekend veld heeft (dat in de tabel zit).

 

[JohanRVT]

De uitslag van een berekening in een query wordt heel geregeld opgeslagen in een tabel omdat er over de tijd aanpassingen kunnen gebeuren (BTW % kan veranderen en verkoopprijzen fluctueren soms dagelijks). Maar dan is dat natuurlijk een gewone tekst - of numerieke waarde in een gewoon veld en zet je daar ook best nog 's de datum van berekening of aanpassing naast, dan heb je een mooi overzicht van de aanpassingen. AD heeft het volgens mij, jammer genoeg, wel degelijk over een veld in een tabel zelf waar een berekening wordt in uitgevoerd. Geen idee wie die cursus gegeven heeft maar dat is toch niet slim geweest.

 

[OctaFish]

Uit oogpunt van dataredundantie probeer je zo weinig mogelijk data dubbel op te slaan. Een uitzondering maak je voor waarden die aan fluctuaties onderhevig zijn, zoals artikelprijzen. In een bestelling wil je altijd de prijs zien van het artikel op het moment van bestellen. Zou je de prijs koppelen met de tabel Artikelen, dan heb je dus een probleem als de prijs verandert. Je ziet dan in de oudere bestellingen ook de nieuwe prijs. Dat wil je uiteraard niet. Daarom wordt de prijs vaak bij het aanmaken van een bestelling uit de tabel Artikelen gehaald (actuele prijs) en opgeslagen in een eigen veld (vaste waarde).
Dat kun je met BTW percentages ook doen, maar dat zou mijn insteek eerlijk gezegd niet zijn. Een btw percentage kan wel eens veranderen, maar dat zal sporadisch voorkomen. Ik gebruik dan een tabel BTW met daarin voor de verschillende categorieën het juiste percentage en de ingangsdatum. Bij de berekeningen zoek ik dan het juiste percentage op in de tabel BtW. Dat gebeurt dan op basis van een functie die zo'n beetje zoals de Vert.Zoeken functie in Excel werkt.
Deze constructie (Opzoeken van prijs op basis van datum) kun je ook gebruiken voor de artikelprijzen. Je zet de artikelprijzen dan in een ruimere tabel waarbij je voor elke mutatie een nieuw record maakt met de prijs in de ingangsdatum. Voordeel daarvan is dat je de prijshistorie behoudt. Je kunt daar dus op rapporteren mocht je dat willen. En je voorkomt dus dataredundantie.

Hoe dan ook: berekende velden in tabellen zijn totaal niet nodig, en waarom Microsoft ze heeft ingevoerd? Zal wel weer een interne weddenschap zijn geweest (wie heeft het gekste idee waar we de gebruikers mee kunnen zieken?). Het geinige is: als je dat veldtype gebruikt, ben je in één klap de compatibiliteit met alle andere database systemen kwijt . Schitterend toch als je ooit besluit om te migreren naar (bijvoorbeeld) SQL server?