Keuzelijst met invoervak ... onjuiste weergave.

[RadboudAKF]

Ik heb 2 tabellen:

-Documenten
-TblStabiliteit

De Tabel Documenten dient om bepaalde documenten vast te leggen.
Er is een documentnummer en een naam. Documentnummer is zodanig opgebouwd dat het een samenstelling is van een Jaartal, een liggend streepje, een volgnummer, een liggend streepje,Initialen. (Bv. 2014-001-HK)

In de tabel tblStabiliteit zit een koppeling met het documentnummer-veld uit de tabel Documenten, zodanig dat er een één op véél relatie kan ontstaan.

Als ik het documentnummer wil ‘ophalen’ met een keuzelijst dan zie ik geen ‘liggend streepje’ meer maar: 2014001HK daar waar ik 2014-001-HK in de tabel zie staan.

Wie ziet waar ik de fout in ga? Ik begrijp niet wat ik verkeerd doe.... (zip bestand toegevoegd)

Jan

 

[OctaFish]

Ik zou zeggen: haal je invoermasker weg en je ziet waarom .

 

[RadboudAKF]

Beste OctaFish,

Heb niet veel ervaring met invoermaskers, maar ik gebruik invoermasker 0000"-"000"-">LL. (heb dat nu ook in de keuzelijst gezet) Ik heb dat aangepast in de toepassing maar het effect is hetzelfde.
Ik begrijp hier echt helemaal niets van (ben daar al een ochtend mee bezig en het resultaat blijft nihil. Sorry, maar ik zie niet waar ik mijn invoermasker verkeerd zet?

Jan

 

[OctaFish]

Ik heb niet gezegd dat je het invoermasker verkeerd heb neergezet, ik zeg alleen dat je een invoermasker gebruikt. En dat je dus kunt zien als je dat weghaalt wat je dus echt opslaat in je tabel. Maar dat laatste hoef ik je niet te vertellen, want dat zie je al in je keuzelijst .

 

[RadboudAKF]

Beste OctaFish,

Ik lees: "Ik zou zeggen: haal je invoermasker en je ziet waarom" Wist even niet wat je bedoelde. Ofwél haal "weg" ofwel haal "op" . Ik ga nu dus haal "weg" proberen....

En ja...ik begrijp eigenlijk niet waarom dit zo is....maar het werkt. Ik wilde in de tabel Documenten met het invoermasker afdwingen dat men twee liggende streepjes invoert....en twee hoofdletter gebruikt op het eind. Dat dit daarna dan niet als basis kan dienen voor de keuzelijst begrijp ik niet helemaal.

Zeer bedankt...

Jan

 

[PFL]

Als je dat wilt afdwingen dan kun je het invoermasker handhaven en vervolgens bij de eigenschap 'Notatie' in BEIDE tabellen het volgende invoeren: @@@@-@@@-@@

Overigens raad ik je aan om tabellen zo neutraal (generiek) mogelijk te houden en niet teveel eigenschappen 'onwrikbaar' vast te leggen. De meeste eigenschappen (en nog veel meer) kun je ook vastleggen in formulieren en dat heeft als voordeel dat je meerdere formulieren kunt maken gebaseerd op dezelfde tabel(len) maar met verschillende eigenschappen en met verschillende doeleinden.
Om dezelfde reden maak ik bij voorkeur ook 'losse' queries i.p.v. queries die ingesloten zijn in een formulier of tabel.

Nog een tip: de velden in een query hebben ook een (klein) eigenschappen-menu waar je het een en ander kunt instellen.

 

[OctaFish]

Als je dat wilt afdwingen dan kun je het invoermasker handhaven en vervolgens bij de eigenschap 'Notatie' in BEIDE tabellen het volgende invoeren: @@@@-@@@-@@

Nee. Notatie en Invoermasker zijn in beginsel alleen weergave aanpassingen aan een veld, maar doen niks met de opgeslagen waarde.

Overigens begrijp ik niet waarom je de waarde (nu weer voor TS) laat invoeren; dit soort gegevens kun je prachtig met een functie automatisch laten maken. Ik neem aan dat het jaartal is gebaseerd op ofwel de huidige datum, ofwel een datum uit een ander veld, het volgnummer automatisch moet ophogen met 1 (weet de gebruiker dat, en hoe weet-ie het laatste nummer?) en dat de letters op het eind de inlogcode van de gebruiker zijn. Allemaal gegevens die je kunt terugvinden in de db, en op basis waarvan je dus simpel een nieuw nummer kunt genereren.

 

[OctaFish]

Overigens raad ik je aan om tabellen zo neutraal (generiek) mogelijk te houden en niet teveel eigenschappen 'onwrikbaar' vast te leggen. De meeste eigenschappen (en nog veel meer) kun je ook vastleggen in formulieren en dat heeft als voordeel dat je meerdere formulieren kunt maken gebaseerd op dezelfde tabel(len) maar met verschillende eigenschappen en met verschillende doeleinden. Om dezelfde reden maak ik bij voorkeur ook 'losse' queries i.p.v. queries die ingesloten zijn in een formulier of tabel.

Het is juist goed om zoveel mogelijk eigenschappen vast te beitelen in tabellen om uniformiteit in gegevens te waarborgen. Persoonlijk zou ik er horendol van worden als één veld er in verschillende formulieren totaal anders uit zou zien. Moet er niet aan denken! Bovendien scheelt het een boel werk omdat je in je formulieren dan bijna niks meer hoeft te doen voor die velden, want formulieren nemen de eigenschappen altijd netjes over. Losse queries gebruiken voor formulieren is op zich prima, maar niet vanwege de aangedragen reden. Maar omdat je in je formulier anders geen keuzelijsten kunt maken waarmee je records kan zoeken binnen het formulier.

 

[RadboudAKF]

Bedankt voor alle suggesties, tips en opmerkingen.

De tip van OctaFish (...) "en op basis waarvan je dus simpel een nieuw nummer kunt genereren" (...) ga ik meteen toepassen. Heb daar stom genoeg niet eerder aan gedacht. En inderdaad: ik volg steeds de methode om zoveel mogelijk vast te leggen in de basis (in de Tabellen dus). Mijn ervaring is dat je daar veel voordelen van hebt als je formulieren /rapporten maakt.

Bedankt voor alle tips en suggesties.

Ik zal dit item sluiten....

Jan

 

[PFL]

Nee. Notatie en Invoermasker zijn in beginsel alleen weergave aanpassingen aan een veld, maar doen niks met de opgeslagen waarde.

Dat is waar, had ik even niet aan gedacht. Des te meer reden trouwens om dat soort dingen in een formulier te regelen en niet in de tabel.

 

[PFL]

Het is juist goed om zoveel mogelijk eigenschappen vast te beitelen in tabellen om uniformiteit in gegevens te waarborgen. Persoonlijk zou ik er horendol van worden als één veld er in verschillende formulieren totaal anders uit zou zien. Moet er niet aan denken! Bovendien scheelt het een boel werk omdat je in je formulieren dan bijna niks meer hoeft te doen voor die velden, want formulieren nemen de eigenschappen altijd netjes over. Losse queries gebruiken voor formulieren is op zich prima, maar niet vanwege de aangedragen reden. Maar omdat je in je formulier anders geen keuzelijsten kunt maken waarmee je records kan zoeken binnen het formulier.

Ik heb andere ervaringen. Ik werd er juist moe van om formulieren aan te moeten passen omdat ik teveel zaken vastgelegd had in de tabellen :d
Uiteraard zorg ik er wel voor dat de uniformiteit van de gegevens gewaarborgd is.

 

[OctaFish]

1Des te meer reden trouwens om dat soort dingen in een formulier te regelen en niet in de tabel.

Oef, dat vind ik dus ECHT een hele foute instelling .

 

[PFL]

Oef, dat vind ik dus ECHT een hele foute instelling .

Ik denk dat je mij verkeerd begrijpt. Ik leg bijvoorbeeld geen invoermaskers en keuzelijsten met invoervak vast in tabellen omdat je die alleen nodig hebt als je een formulier maakt voor gegevensinvoer en/of gegevenswijziging. Als je vervolgens een formulier maakt, gebaseerd op dezelfde tabel, waarmee alleen gegevens opgevraagd kunnen worden dan heb je die invoermaskers en keuzelijsten helemaal niet nodig en moet je ze weer verwijderen.

Is overigens niet bedoeld om mijn gelijk te halen. Je hebt in principe wel gelijk maar persoonlijk vind ik het niet altijd handig om alles vast te leggen in de tabellen.
Maar misschien gebruik ik Access niet 'zoals het hoort'. Ben grotendeels autodidact.

 

[OctaFish]

Ik denk dat we naast elkaar dachten; ik vind namelijk ook dat je zo min mogelijk in een tabel moet vastleggen. Dus géén invoermaskers (nooit nodig gehad, en dat gaat niet gebeuren ook. Hooguit voor Postcodes handig), maar wél notatiewijze bijvoorbeeld. Want je wilt wel dat de gegevens er uniform uitzien. Maar Notatie verandert niks aan de waarden die je opslaat, dus dat is niet erg verder. Dus gegevenstypes goed instellen (Geld als valuta, getallen als gehele getallen voor getallen die dat nodig hebben), tekst voor velden waar je niet mee rekent of waar je niet numeriek op wilt sorteren (zoals telefoonnummers etc). En bovenal: nooit (lees: echt absoluut NOOIT) keuzelijsten in tabellen op basis van tabellen . Uitgangspunt moet ten ene male altijd zijn: in een tabel moet je altijd kunnen zien wat er letterlijk is opgeslagen.