aanvullen zonder keuzelijst ( vanuit textvlak)

Status
Niet open voor verdere reacties.

Louche

Gebruiker
Lid geworden
14 jan 2012
Berichten
15
Hallo allemaal ,
Ik ben net begonnen met iets te maken in access, wat tevens ook mijn eerste access projectje is.

De simpele dingen zoals iets wegschrijven in een tabel willen al wel lukken. Maar nu stuit ik dus op een eerste probleem. Na het afspuiten van de zoekfunctie kom ik altijd tot het resultaat van het gebruik van een keuzemenu en dit wil ik dus vermijden.

Ik heb gegevens over een product staan in 1 tabel. ( leverancier, referentie, omschrijving van het product, aantal in een verpakking, enz…)

Op mijn formulier staan deze velden ook. Nu wil ik dat al deze velden ingevuld worden aan de hand van alleen de referentie. Dus NIET via een keuzelijst! Enkel door 1 tekstveld in te vullen. ( dat van de referentie.)
Wat zijn mijn mogelijkheden hierin. Heb al van alles geprobeerd zoals query, macro, module. Maar geraak er maar niet uit.
En dan een 2de probleem al deze gegevens moeten naar 1 gecentraliseerde andere tabel gaan . omdat sommige gegevens uit mijn eerste tabel soms wijzigen. Deze gegevens en die van een sub formulier zouden dus naar een nieuwe tabel moeten gaan.

In het sub formulier worden een aantal ingegeven een bruto gewicht en een keuze gemaakt uit verschillende verpakkingen. De rest word berekent ( netto, tarra, netto/colli, afwijking) nu worden alleen de gegevens die ikzelf invul weggeschreven en niet die dat berekend worden. Wat doe ik hier verkeerd mee.

Er zullen nog wel problemen opduiken maar als iemand mij hier al wegwijs in kan maken dan ben ik al een heel eind opweg.

Hopelijk kunne jullie een beetje uit aan mij uitleg die wss ingewikkelder is dan de oplossing ervoor.
Als het te onduidelijk is kan ik eventueel de access file ergens uploaden. Ik gebruik zelf 2010 maar de file is gesaved als een 2000 versie .

Alvast bedankt
 
Om te beginnen: is het veld Referentie het sleutelveld van je producten tabel? En wat heb je tegen keuzelijsten (met invoervak)? Keuzelijsten hebben de briljante eigenschap dat je meerdere kolommen kunt laten zien in de lijst, die je vervolgens relatief simpel op je formulier kunt laten zien en opslaan in je tabel. Door een tekstveld te gebruiken bouw je een foutmogelijkheid in voor de gebruiker, die daar vast niet op zit te wachten. Sterker nog: een beetje ontwerper probeert alle foutmogelijkheden zoveel mogelijk te elimineren! Eigenlijk is het antwoord op je eerste en tweede vraag dus: maak een keuzelijst....

Je derde vraag krijgt hetzelfde antwoord: de berekende velden moet je, als je de waarden wilt opslaan, (al is één van de hoofdregels van een goede db dat je berekeningen nooit opslaat; een regel die je dus aan je laars lapt) koppelen aan velden in de tabel. Het berekenen zelf doe je op basis van de velden die gebruikt worden voor de berekening. De formule zet je dan dus niet in de eigenschap <Besturingselementbron>.
 
Hey OctaFish,

Bedankt voor de snelle reactie,
om eerst te antwoorden op jou vraag de referentie is niet het sleutelveld, maar ID. Heb eerlijk gezegd geen idee waar die 'benaming' voor staat.
Ik heb trouwens niets tegen keuzemenu's, maar zal ff het hele verhaal in het kort schetsen waarom ik liefst een tekstvak heb. Er worden producten gewogen en deze worden opgeschreven op een papier. op dit papier staat de benaming en de (unieke)referentie van het product, het lijkt mij het simpelste voor de gebruiker die de gegevens moet invoeren om de referentie in te geven. in plaats van tussen een 100tal referenties te moeten gaan zoeken.

Over de berekeningen daar had ik nog niet bij stilgestaan dat deze eigenlijk niet moeten opgeslagen worden mits deze uiteindelijk ook bij het rapport kunnen berekend worden. dat hoeft dus idd niet meegenomen te worden naar een tabel.

Wel had ik graag de datum bovenaan mijn form " =date() " meegenomen naar de tabel evenals 2 gegevens die gekozen worden uit 2 keuzelijsten. en deze krijg ik dus ook niet in de nieuwe tabel ingevoerd.

uiteindelijk is het de bedoeling dat als ik vandaag 5 pallets weeg van de ref xxxx dat ik vandaag ook in mijn rapport krijg dat die 5 pallets gewogen zijn dat die op palletsoort X ( keuzelijst 1) stonden en in bakje Y (keuzelijst2) zaten. deze gegevens samen met die dat die ik reeds wel inde tabel kreeg (bruto, aantal colli,... ) moeten bewaard blijven zodat ik in de toekomst nog altijd kan zeggen op die dag hebben wij van die referentie zoveel pallets gewogen en dat zat toen in die verpakking. maar zoals ik al zei de keuze's die uit de keuzelijsten gemaakt worden gaan niet naar die tabel. wel word het tarra en netto berekend op het formulier zelf afhankelijk van de keuzes uit diezelfde menu's. maar deze ga ik dus niet bewaren zoals je al aanrade.
 
de referentie is niet het sleutelveld, maar ID. Heb eerlijk gezegd geen idee waar die 'benaming' voor staat.
ID is een veldnaam die Access bedenkt als je een tabel maakt zonder sleutel(veld). Je krijgt dan een vraag of je een sleutelveld wilt toevoegen, en als je op Ja klikt, krijg je dat veld erbij. Dat heb je dus gedaan bij het maken van de tabel. Als je referentie veld niet als sleutel is gedefinieerd, dan moet minstens de eigenschap Geïndexeerd op Ja, Geen duplicaten staan, anders heb je een onoverkomelijk probleem... Maar je zegt al in je verhaal dat Referentie uniek moet zijn, dus daar zou ik dan een sleutelveld van maken, en het ID veld weggooien.

het lijkt mij het simpelste voor de gebruiker die de gegevens moet invoeren om de referentie in te geven. in plaats van tussen een 100tal referenties te moeten gaan zoeken.
Dat zie je dus helemaal verkeerd, want juist met Keuzelijsten kun je veel makkelijker gegevens zoeken dan via een apart tekstveld. Op dat tekstveld kun je namelijk alleen een check doen als het volledig is ingevuld. Maak je een fout, dan kun je opnieuw beginnen. Met een keuzelijst zoekt Access al gelijk vanaf het eerste teken dat je typt de eerste waarde die voldoet aan de zoekstring, en naarmate je meer typt, wordt de lijst kleiner en vind je de (per definitie altijd aanwezige) zoekwaarde vele malen sneller. En daar heeft Microsof ze ook voor bedoeld ;)

Wel had ik graag de datum bovenaan mijn form " =date() " meegenomen naar de tabel evenals 2 gegevens die gekozen worden uit 2 keuzelijsten. en deze krijg ik dus ook niet in de nieuwe tabel ingevoerd.

Keuzelijsten moet je, als je de waarden wilt opslaan, koppelen aan een veld in je tabel. Dat lijkt mij zo te lezen geen probleem te hoeven opleveren. Kwestie van Besturingselementbron instellen. Hetzelfde geldt voor de keuringsdatum. Datumvelden kun je nog (in tabel of op formulier) een standaardwaarde meegeven, zodat je die niet eens zelf hoeft in te voeren. Wil je alleen de datum: dan =Date() of =Datum(). Wil je ook de tijd erbij: dan =Now() of =Nu()
 
Heb er dan toch een keuze lijst van gemaakt en met de "=[referentiekeuze].[Column](2)" gewerkt . alle velden worden ingevuld zoals ik wou. Waarvoor dank.

heb nog wel het probleem met de datum juist weg te krijgen naar mijn tabel, in mijn formulier krijg ik mooi de datum van vandaag met =date() maar krijg hem niet weggeschreven naar mijn gegevenstabel heeft wss iets te maken omdat deze op mijn hoofdformulier staat en de rest van mijn gegevens op mijn subformulier want de referentie (eveneens op mijn hoofdformulier) neemt hij ook niet mee uit het keuzevak. maar heb ondertussen mijn query een beetje verprutst. Ga deze dus eerst nog is opnieuw maken en het forum een beetje doorlezen over het wegschrijven van data.

Nog snel een afsluitende vraag. is het mogelijk om een formulier met checkboxes automatisch te laten opbouwen aan de hand van een tabel.

bv een formulier dat automatisch een checkbox maakt voor elke referentie en deze daar dan ook achterplaats. of moet je formulieren altijd zelf opbouwen.

alvast bedankt voor de hulp en wss hoor je nog wel van mij met een ander probleem :rolleyes::rolleyes:
 
Je kunt interactief formulieren bouwen op basis van waarden uit een tabel, maar dat is een gruwelijke hoop programmeren.... Daar zit je vermoedelijk niet op te wachten!
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan