kzl met invoervak eerst sorteren nav waarde in ander veld

Status
Niet open voor verdere reacties.

Friend

Verenigingslid
Lid geworden
31 jan 2009
Berichten
1.137
Beste forummers,

Op een formulier heb ik een kzl met invoervak. Zie bijlage.Bekijk bijlage Database4.rar

De keuze lijst begint met een jaar en dan een omschrijving. Dus bv 2016-fietsen
Door de meerdere jaren die in de keuzelijst staan wordt deze echter te lang.

Kan ik bij het openen van de keuzelijst deze eerst laten kijken en filteren op het veld jaar? Waar dan bv 2016 in staat?

Friend
 
Waarom gebruik je maar één veld in je tabel kzlOnderwerp? Ik zou sowieso de onderwerpen los gooien van het jaartal, en dat genereren op basis van het actieve jaar. Nu heb je overal dubbele waarden in staan met een jaartal erbij. Volgens mij is dat nergens voor nodig.
 
Michel,

Hartelijk dank voor je reactie :thumb:

De originele kzl heeft ook nog een kolom prijs.

Elk jaar verandert de prijs.

Nu zal jij daar ook wel een mooie oplossing voor hebben :) alleen ik niet.

Dus moet het roer om of wat is jouw advies en oplossing?

Friend
 
Hangt er vanaf of je de historie wilt bewaren van je artikelen. Sowieso heb ik een oplossing :).
 
Michel,

Ja ik wil graag de historie van de artikelen bewaren.

Friend
 
In dat geval moet je aan een prijzentabel denken met een begindatum en einddatum. Bij elke wijziging maak je dan een nieuw record. In de keuzelijst zoek je dan de prijs op op basis van de datum en artikelnummer.
 
Michel,

Ik heb de tabellen en het form aangepast alleen hoe krijg ik dit voor elkaar :

In de keuzelijst zoek je dan de prijs op op basis van de datum en artikelnummer.

Wat moet ik doen om nu in de keuzelijst alleen de artikelen/prijzen te krijgen gefilterd op het veld jaar?

Friend

Bekijk bijlage Database4.rar
 
Om te beginnen zou ik in je tabel tblPlanning met datums werken en niet met jaren. Al was het maar omdat je de prijzen flexibel wilt kunnen aanpassen, en niet alleen op 1 januari. Als je dat doet, kun je de gewenste filtering maken.
Overigens snap ik niet waarom je een keuzelijst met een mooi tekstvak helemaal verkleint zodat je een apart tekstvak nodig hebt om de gekozen waarde te laten zien. Alleen maar omdat je het keuzevakje links van de tekst wilt i.p.v. rechts? Dan ben je een nog grotere opmaakmasochist als ik :). Op zich ook wel weer een complimentje waard :D. Bovendien kunnen de gebruikers nu niet meer in de keuzelijst zoeken door letters in te typen. Dus het gebruikersgemak gaat er flink op achteruit. Of was dat nou juist de bedoeling? Ook een reden voor respect ;).

In je huidige db kun je de keuzelijst nu simpel filteren op het huidige jaar:
Code:
SELECT betreft, begindatum, einddatum, prijs FROM tblAktiviteit WHERE ([Jaar] = Year(Date) ORDER BY [betreft];
Maar dit is niet half zo leuk als filteren op de juiste actieve prijsdatum.
 
Je loopt in je antwoord netjes om de vraag heen of je met opzet het gebruikersgemak om zeep wilt helpen :). En dit argument?

Dat vind ik inderdaad mooier, ach ja en beetje hobbyen
Gebruikers (en jij bent er daar zelf ongetwijfeld ook één van) hebben door de jaren heen een bepaalde perceptie opgebouwd van hoe objecten in formulieren werken. Zo weet iedereen dat je bij een aantal selectievakjes meerdere opties kunt kiezen en bij radiorondjes uit de aangeboden opties één optie. En bij keuzelijsten staat de afrolknop altijd rechts. Deze conventies zijn niet voor niks (zo goed als) vastgelegd; een gebruiker wil bepaalde automatismen in zijn GUI. Die verwacht hij ook. Door daar moedwillig aan te gaan rommelen omdat je dat mooier vindt vind ik nogal wat.... Zeker als je systemen maakt waar anderen mee moeten werken (ik weet natuurlijk niet of dat zo is) vind ik dat je eigen smaak ondergeschikt moet zijn aan de functionaliteit van het product. Wil niet zeggen dat je geen eigen opmaak en layout mag verzinnen, maar hou je bij voorkeur aan de algemeen aanvaarde conventies, zou ik zeggen.
Ik kom overigens in dit forum al vaak genoeg databases tegen waar de bouwer rustig radiorondjes gebruikt voor meervoudige selecties 'omdat ik dat mooier vind'. Vraag je het mij op de man af dan zeg ik: weg met dat ego en denk aan je gebruikers. Waarschijnlijk overleeft de database jouw aanwezigheid in het bedrijf :).

Back on topic:
In VBA heb je geen haakjes nodig bij Date; in een query wel. Dus hij moet zo:
Code:
SELECT betreft, begindatum, einddatum, prijs FROM tblAktiviteit WHERE (jaar=Year(Date())) ORDER BY [betreft]
 
Michel,

Bedankt voor de aanvulling :thumb: Ik dacht eerst even dat je mij wilde laten studeren.

Je advies nemen we ter harte :):) Zo leer ook ik weer bij! Dus wordt het toch studie;)

Maar we willen nu toch wel aanpassen m.b.t. jouw opmerking, als jij zegt dat het leuker wordt dan geloof ik je direct :D :

Maar dit is niet half zo leuk als filteren op de juiste actieve prijsdatum.

Hoe moet ik dan daar de code voor aanpassen.

Friend
 
Dan heb ik een deebeetje nodig met de juiste data. Ik help graag, maar ben geen typgeit :)
 
Je had die geit nog niet op moeten eten, want met één record schiet het natuurlijk niet op. Bovendien vind ik de soort gegevens ook niet geweldig. Ik vraag me af of je ene record een reële situatie voorstelt. Dat ene planningrecord loopt, net als je tarieventabel, van 1 januari t/m 31 december. Verder heb je in de tabel Tarieven 2 tarieven voor 'boot' ingevoerd, terwijl Boot geen record is in de tabel Onderwerp. Kortom: hoe bruikbaar is deze database?
 
Status
Niet open voor verdere reacties.
Terug
Bovenaan Onderaan