[Access]Tabelweergave vanuit knoplink

[Briefcase]

Wanneer je een knop maakt om een formulier te openen vanuit een ander formulier, krijg ik automatisch de formulier-weergave. Maar in het te openen formulier staat ingesteld dat het standaard gegevensblad-weergave moet zijn.

En dit alles wordt mogelijk gemaakt door Access 2002. Iemand ideeën?

[BertS]

Visual Basic:

DoCmd.OpenForm "frmTest", acDatasheet

(of zoiets )

[Briefcase]

bee-es schreef op vrijdag 03 juni 2005 @ 18:57:

Visual Basic:

DoCmd.OpenForm "frmTest", acDatasheet

(of zoiets )

Nu is mijn VB niet al te best, maar dit werkt niet. Hij opent weer met formulierweergave

code:

 stDocName = "Signalering"
    DoCmd.OpenForm stDocName, , , stLinkCriteria, acDatasheet

of

code:

 stDocName = "Signalering"
    DoCmd.OpenForm stDocName, acDatasheet , , stLinkCriteria,

[BertS]

Ok, ik heb nu even de moeite voor je genomen om de editor te openen

Visual Basic:

DoCmd.OpenForm "frmTest", acFormDS

[Briefcase]

bee-es schreef op vrijdag 03 juni 2005 @ 20:54:
Ok, ik heb nu even de moeite voor je genomen om de editor te openen

Visual Basic:

DoCmd.OpenForm "frmTest", acFormDS

je bent fantastisch!

Dank je wel.

Nog even een vraag erachter aan wanneer het u belieft:

> Het is een klanten database en de vraag is; Hoe voorkom je dat er klanten, dubbel worden ingevoerd?

[chicky]

door een selectie query te schrijven, waarmee je vergelijkt of de klant die je invoert al bestaat.
Deze query moet je uitvoeren als je alles heb ingevuld. je gaat dus kijken of de klant wel of niet mag worden toegevoegd. Als de klant mag worden toegevoegd is alles oke, anders een messagebox openen, waarin je zegt dat de klant al bestaat en het formulier leeg maken (of iets minder drastisch)

[ Voor 73% gewijzigd door chicky op 03-06-2005 21:06 ]

[Koppensneller]

Eehm, primary keys?

[BertS]

Hmm, in veel gevallen valt het niet voor 100% te voorkomen.
Primary keys (of unieke indexen) lijken hiervoor geschikt, maar zijn alleen zinvol voor toepassing van unieke codes (bijv. voor controle op dubbele klantnummers). Klantnamen worden door elke gebruiker in een andere vorm ingevoerd, dus daar valt in de praktijk niet zo eenvoudig op te controleren (iig niet waterdicht te krijgen). Uiteraard kun je wel eisen dat klantnaam uniek is, dan komt dezelde notatie iig niet meerdere keren voor

[Koppensneller]

Je kunt toch vakken maken voor Achternaam, Voornaam en Tussenvoegsel? Waarbij tussenvoegsel dan natuurlijk NULL kan zijn.

Wat ik sowieso niet zou doen is een primary key hangen aan alleen de naam van de klant. Pak er dan op zijn minst de postcode bij, want twee klanten met dezelfde naam is natuurlijk heel goed denkbaar...

[BertS]

hugodejong schreef op zaterdag 04 juni 2005 @ 02:06:
...want twee klanten met dezelfde naam is natuurlijk heel goed denkbaar...

Bij particulieren wel ja (maar daar kan het ook goed bij dezelfde postcode, en zelfs op hetzelfde huisnr, bijv. huisgenoten met dezelfde voorletters )
Bij bedrijven is de kans op meerdere keren dezelfde naam zeer klein imo.

[Koppensneller]

Dat is inderdaad zo, en dat zal de TS moeten afstemmen op zijn eigen situatie...

[Briefcase]

In dit geval gaat het om een database met bedrijfsnamen. Dus dat zal het probleem niet zijn. Het enige probleem is mijn VB.

Heeft iemand tips voor zo'n scripje of een linkje naar een goede VB FAQ voor dit soort dingen?

[Briefcase]

ik heb hem toch op primary key gezet. Dat schijnt allemaal wel goed te gaan. Ik ga er vanuit dat we wel weten hoe die klant ingevoerd moet worden. Helemaal idiot-proof zal het wel niet worden, maar dat geeft niet.

Bedankt voor de hulp!