[ACC 2007] Record source van formulier met Tab control

[Josh]

In principe is dit een lichtelijk open vraag.

Ik heb een database met waarvan de vier hoofdtabellen informatie over een bestelling van een product bevatten. In principe is de data een-op-een gerelateerd, maar is de data gegroepeerd in vier tabellen om de overzichtelijkheid te bewaren.

Nu wil ik graag een formulier maken waarmee een gebruiker een nieuwe order kan toevoegen of een order kan wijzigen. Door de grote hoeveelheid aan informatie wil ook dit formulier opsplitsen, door middel van tabs. Goed idee tot nu toe, of niet?

Het probleem is echter dat een formulier maar 1 'Record Source' kan hebben, terwijl er 4 tabellen zijn met informatie. In eerste instantie leek dat op te lossen door een stukje VBA te schrijven dat de record source veranderd wanneer de juiste tab geselecteerd wordt. Nou is het zo dat ik data per tab niet specifiek aan een tabel wil binden. Bovendien zal de VBA niet simpel zijn omdat hetzelfde formulier gebruikt moet worden voor het aanpassen van data en er dan vind ik het lastig om voor iedere tab de juiste record te wijzigen.

Natuurlijk is het mogelijk om het formulier te ontbinden (unbound) en vervolgens handmatig de data op te slaan met een 'Save' knop. Echter betekend dat er voor ieder veld VBA geschreven moet worden.

Ik heb het idee dat ik hier de plank mis sla, want voor mijn gevoel moet dit toch veel simpeler kunnen. Er zijn tal van voorbeelden waarbij een 'tabbed form' naar meerdere tabellen data wegschrijft, maar hoe?

[Marko_J]

Als je in elke tab een subformulier kunt opnemen, dan word je wat onafhankelijker; elk subformulier heeft z'n eigen recordset.


Overigens;
Ik zou alleen tabs gebruiken voor verschillende categorieen gegevens. Dus bijvoorbeeld:

Bedrijf
[personen] [orders] [facturen]

Als je tabs gaat maken voor een en hetzelfde ding, bijvoorbeeld [order 1] [order 2] [order 3], dan wordt het er niet duidelijker of makkelijker op voor de gebruiker. Zeker als het een handeling is die vaak gedaan gaat worden, dan is een formulier wat je van A tot Z kunt doorlopen met de tab-toets wel zo handig. Gebruikers krijgen daar snel routine in.

[Josh]

Ik maak inderdaad een tab formulier voor verschillende onderdelen/categorien van de order.

Subforms per tab heb ik inderdaad geprobeerd maar ik loop dan vast als ik een bestaande record wil aanpassen. Hoe zorg ik ervoor dat alle tabs (en dus alle subforms) dezelfde dataset aanpassen? De data is tussen de tabellen gelinkt, maar ik er is geen relatie tussen de subforms.

Mijn kennis van VBA is ietswat karig zoals je wellicht al opgemerkt hebt ;-)

[Moirraine]

Alles omwille van overzichtelijkheid opsplitsen in meerdere tabellen is (meestal/haast altijd) een slecht idee, maar als je in VBA ook bepaalde waardes in het form zet terwijl dezelfde record ook in een ander form open staat, ga je schrijfconflicten krijgen (form 1 ziet de wijziging niet direct zonder een handmatige requery in VBA), dus dan kan het opsplitsen een oplossing zijn, hoewel het verre van chique is. Bovendien zul je dan een recordset moeten openen met alle records die eigenlijk het zelfde zijn en die editen en updaten. Foutgevoelig, veel werk en eigenlijk compleet onnodig als je alles in 1 tabel gooit. Ik weet dat er er verschillende meningen zijn over Access, maar zulke dingen moet je niet zelf willen regelen, daar is Access zelf namelijk al goed in als je datamodel goed is. Je datamodel is de basis van elke DB, als die rammelt ga je zooooo veel overhead, onnodig werk en op den duur onoverzichtelijkheid creëren dat een iets uitgebreidere voorfase zich haast altijd weer terugbetaald en dat vermoeden is er wel sterk bij mij.

Als ik je verhaal snel scan is het dan geen idee om alles WEL in 1 grote tabel te plempen (er van uit gaande dat de db wel genormaliseerd is), een tab control gebruiken en dan op pagina 1 alle controls die betrekking hebben op die knop (tab 1 zet je het ordernummer en besteldatum, tab 2 komen de controls mbt de betalingsafspraak, tab 3 toon je aan de hand van je klantID de klant gegevens (er van uit gaande dat die wel netjes in een andere tabel staan), etc), zonder sub forms?

Alles unbinden is trouwens vaak veel werk. Waarom geen opslaan/annuleren knop?

Op het hoofd form doen je bij subform_Exit (als je het opgesplitst laat en in subformulieren doet)

code:

 if me.subformX.form.dirty = true then 
msgbox "Er zijn wijzigingen op dit formulier aangebracht. Sla eerst op of annuleer",vbexclamation + vbokonly, "Validatie"
cancel = -1 
Else
Cancel = 0
End if

Opslaan doe je met

code:

If me.dirty = true then me.dirty = false

Annuleren

code:

If me.dirty = true then me.undo

Voor je het subform verlaat (het verlaten van formulier = opslaan in access) kijk je of er wijzigingen zijn in het subform, zo ja, dan verlaat je het subform niet tot de gebruiker opslaan of annuleren heeft geklikt. Minder code, dus minder foutgevoeligheid en dus ook minder rework in de toekomst. Sommige van de beste formulieren die alleen nieuw/wijzigen zijn, hebben vaak maar 5 tot 10 regels code

[Josh]

Moirraine schreef op woensdag 27 april 2011 @ 11:32:
... Lang maar goed verhaal ...

Je hebt eigenlijk helemaal gelijk, ik moet terug naar de basis en dat is mijn databasemodel. Ik ben hierin veel te amateuristisch en het is een database die ik niet zelf heb opgezet. Ondanks dat het lichtelijk offtopic is wil ik kort verklaren waarom ik de splitsing gemaakt heb, dan kun je wellicht wat beter bepalen of het een dom idee was of niet. Helaas moet ik een aantal dingen kriptisch beschrijven (of simpelweg onherkenbaar maken), want ik werk voor een groot bedrijf dat graag zoveel mogelijk informatie voor zichzelf houdt.



Zoals je kunt zien gaat het om erg veel informatie, dus je zult begrijpen dat mijn onervaren databasebrein dacht dat opsplitsen 'overzichtelijker' zou zijn. Bovendien is er in de praktijk ook sprake van een opsplitsing, zo kan een order meerdere (identieke) productverzamelingen hebben, maar productenproductverzamelingen hebben altijd met een uniek ID. Met andere woorden, een productverzameling met serienummer X komt nooit in een andere order voor en vandaar de 1:1 relatie.

De tabel met productverzamelingen (tweede), heeft een of twee hoofdproducten met enkele bijproducten die niet door ons gefabriceerd worden. In de illustratie is Second Product niet gekoppeld aan de productentabel, maar dat is eigenlijk wel zo. Echter geeft dit problemen met validatie en bovendien komt deze combinatie bijna nooit voor.

Op basis van deze informatie, zou het dan nog stees een goed idee zijn om het in een grote tabel gooien? Naar mijn idee niet. Het zou het geheel wel een stuk makkelijker maken wat betreft input en output.

[ Voor 45% gewijzigd door Josh op 28-04-2011 09:58 ]

[Marko_J]

Alles wat bij elkaar hoort, hoort in 1 tabel inderdaad, ook al wordt deze erg groot. Overzicht kan je bewaren door duidelijke veldnamen te gebruiken en goed te documenteren. Als een order uit meer dan 1 product kan bestaan, dan zijn dat dus twee tabellen; Orders en Order_Products oid. Ook al bestaat 99% van de orders uit maar 1 product, het is nooit een goed idee om velden als product_1, product_2 op te nemen in een tabel Orders.

De structuur wordt dan iets als:

Orders
- id
- customer_id
- enz

Order_Products
- id
- order_id (link met order id)
- product_id (link met product id)
- enz

PS: doe jezelf een plezier en gebruik geen spaties in veldnamen. Gebruik underscores bijvoorbeeld. Voorkomt ellende

PPS: niet lullig bedoeld, maar als het om een groot bedrijf en complexe database gaat, waarom zetten ze een onervaren persoon op deze klus?

[Verwijderd]

Marko_J schreef op donderdag 28 april 2011 @ 10:02:
PPS: niet lullig bedoeld, maar als het om een groot bedrijf en complexe database gaat, waarom zetten ze een onervaren persoon op deze klus?

Och jee...ben nu zelf ook met een bijltje aan het hakken dat ik voorheen nog nooit gehanteerd heb. Voornaamste reden in dit geval: geld. Of - vrij vertaald - denken dat een snelle oplossing forceren in Access met een werknemer die in zijn werkzaamheden veel met Access doet, maar het ontwikkelen van Accessapplicaties niet als kerntaak heeft, meer geld gaat besparen dan een off-the-shelf professioneel pakket.

[Josh]

Marko_J schreef op donderdag 28 april 2011 @ 10:02:
Alles wat bij elkaar hoort, hoort in 1 tabel inderdaad, ook al wordt deze erg groot. Overzicht kan je bewaren door duidelijke veldnamen te gebruiken en goed te documenteren. Als een order uit meer dan 1 product kan bestaan, dan zijn dat dus twee tabellen; Orders en Order_Products oid. Ook al bestaat 99% van de orders uit maar 1 product, het is nooit een goed idee om velden als product_1, product_2 op te nemen in een tabel Orders.

De structuur wordt dan iets als:

Orders
- id
- customer_id
- enz

Order_Products
- id
- order_id (link met order id)
- product_id (link met product id)
- enz

Een order dat uit meer dan 1 product kan bestaan is in Access 2007 ook op te lossen met multivalued fields, niet?

PS: doe jezelf een plezier en gebruik geen spaties in veldnamen. Gebruik underscores bijvoorbeeld. Voorkomt ellende

Ja, heb je gelijk in

PPS: niet lullig bedoeld, maar als het om een groot bedrijf en complexe database gaat, waarom zetten ze een onervaren persoon op deze klus?

1. In veel gevallen werkt het sneller als je iets zelf kunt regelen, vaak zijn de procedures voor zoiets in een groot bedrijf enorm lang en ingewikkeld.
2. Deze database is niet zomaar op te lossen met een 'pakket' en het zou betekenen dat er iemand voor moet worden ingehuurd.
3. Het is een database die niet veel personen zullen gebruiken. Oftewel, zoals Alargule zegt, de leiding ziet de meerwaarde niet van het outsourcen hiervan. Wel heeft mijn leidinggevende aangegeven dat hij me graag wil laten opleiden om er meer kundig in te worden, dat is voor hen relatief goedkoop en waardevol.
4. Ik vind het leuk! Ookal ben ik nu onervaren, ik wil graag meer leren. De combinatie met mijn andere werk geeft mij een uitstekende positie aangezien ik precies weet wat er nodig is.

Aangezien dit topic aardig offtopic gegaan is stel ik voor om het te sluiten, ondanks dat ik jullie adviezen erg op prijs stel!

[Marko_J]

Josh schreef op donderdag 28 april 2011 @ 15:00:
Een order dat uit meer dan 1 product kan bestaan is in Access 2007 ook op te lossen met multivalued fields, niet?

Klopt. Heb ik zelf nog niet gebruikt. Deels door oude stempel, deels omdat klanten nog met 2003 werken Voordat je multivalue fields gaat gebruiken, bedenk wel of de database ooit geconverteerd, gekoppeld of geexporteerd moet kunnen worden naar een ander systeem dat wellicht niet overweg kan met dit type (alleen Sharepoint heeft het ook, meen ik)

Daarnaast zijn multivalued fields alleen handig voor het opslaan van 1 soort waarde. In dit voorbeeld zou je alleen product-id's kunnen opslaan die bij een order horen, maar geen extra informatie zoals bijvoorbeeld aantal, prijs, korting, opmerking, etc. Maar dat is in jouw situatie wellicht niet aan de orde.

[redenen]

Fair enough