Synchroniseren records in tabbladen

[tonp60]

Hallo

Ik heb een subformulier met tabbladen in een hoofdformulier. Zie onderstaande screendump.

In het voorbeeld zitten 2 artikelen.
Het 1e tabblad betreft het artikel.
Nu is het zo dat ieder tabblad zijn eigen status laat zien. Of van artikel 1 of van artikel 2. Afhankelijk wat je geselecteerd hebt.
Is het mogelijk dat als op het tabblad Artikel artikel 1 geselecteerd is de overige tabbladen de status laten zien van artikel 1?
Hetzelfde geldt als ik op het tabblad Artikel artikel 2 selecteer dat de overige tabbladen automatisch de status laten zien van artikel 2?
Kortom ik wil alle statussen kunnen zien van het artikel wat op het tabblad Artikel geselecteerd is.
Ik hoop dat ik het probleem duidelijk he kunnen maken.

 

[OctaFish]

Je geeft véél te weinig informatie. Laat ik eerst een misverstand uit de weg ruimen: een tabblad element doet helemaal niets. Het is onzichtbaar voor de acties die je op een formulier doet; heeft dus alleen visuele impact m.b.t. de weergave van je gegevens. Als je dus gegevens ziet in een tabblad, dan is het afhankelijk van de bron van het formulier om te bepalen wát je ziet; het tabblad component heeft daar geen enkele invloed op.

Dat gezegd hebbende: zonder de db te zien, kunnen we dus niet zoveel. Zeker niet op basis van alleen een plaatje.

 

[tonp60]

Duidelijk.
Ik heb een voorbeeld database bijgevoegd. De Db start op met het betreffende hoofdformulier.
Als ik op het tabblad artikel de slaapkamerkast heb geselecteerd (record 1) dan zie ik op alle tabbladen de voortgang van dit artikel
Als ik nu op het tabblad artikel het matras selecteer (record 2) dan zie ik op alle tabbladen nog steeds de voortgang van de slaapkamerkast.
Het is de bedoeling dat ik dan op alle tabbladen tegelijk de voortgang van record 2 zie. Nu moet ik op ieder tabblad opnieuw record 2 selecteren.
Hopelijk kan hier iets mee gedaan worden.

 

[NoellaG]

Gemakkelijkste oplossing, zonder code: zet de selectie van het element in je hoofdformulier, zoiets als:

Bekijk bijlage 355767

 

[OctaFish]

Ik heb even naar je db gekeken, maar wat een chaos! Begin eens met je tabellen fatsoenlijk te normaliseren, en de juiste tabellen aan te maken. Zo heb je in je tabel OrdersArtikelen een enorme bak velden staan die niets met de onderhavige tabel te maken hebben. In die tabel zitten twee artikelen, slaapkamerkast en matras. Nou zou ik heel graag van jou weten wanneer een matras moet worden verzaagd . En toch heb je daar 13 velden voor in je tabel staan! Zorg ervoor dat je tabellen de juiste velden bevatten, en vul ze als je ze nodig hebt. Dus gekoppeld aan een artikelsoort.
Daarnaast heb je de tabel Interieur al helemaal niet genormaliseerd, want daar doe je niet alleen hetzelfde als in te OrdersArtikelen (verkeerde velden gebruiken) maar óók nog eens niet genormaliseerd, dus elk veld(groep) komt ook nog eens meermalen voor, wat een enorme grote tabel oplevert die je ook nog eens behoorlijk in de problemen kan brengen als later blijkt dat je tóch te weinig velden hebt....
Eerlijk gezegd sta ik niet te popelen om op basis van deze db jouw vraag te verhelpen, want ik duw je alleen maar verder het ravijn in .

 

[LucHeyndrickx]

Zoals Octafish al indirect aangaf: je zou best 's de basis van je project herbekijken. Een hoop tabellen kunnen gewoon verdwijnen, maar dan zullen er weer andere moeten bijkomen.
Een voorbeeld:
Je hebt verschillende tabellen waar telkens dezelfde namen in voorkomen:
Werknemer x doet de zagerij; doet de montage enz.
Werknemer y doet de zagerij; de levering enz.

Voor elke afdeling hoef je dus geen aparte tabel te maken om te bepalen welke werknemers er werkzaam zijn.
Eén tabel voor de werknemers (in dezelfde tabel kunnen trouwens ook klanten zitten), en één tabel met de verschillende werkplaatsen. Vervolgens een tabel waar je de werknemers aan één of meerdere werkplaatsen koppelt.

En dan die tabbladen. Elk tabblad met vrijwel dezelfde opbouw, en telkens een ander deeltje van je tabel. Ook dat zou je kunnen vereenvoudigen.

Eerlijk gezegd: mocht ik deze job in handen krijgen, ik begon het terug van de basis opnieuw op te bouwen. Ook ik heb dat al gedaan hoor. Bestanden die ik ooit maakte na verloop van tijd volledig opnieuw opbouwen, met het gevolg dat het uiteindelijke bestand stukken beter is dan ik ooit had kunnen bereiken door een oud bestand steeds opnieuw aan te passen.

 

[OctaFish]

Eén tabel voor de werknemers (in dezelfde tabel kunnen trouwens ook klanten zitten)

Lijkt mij niet handig en zou ik nooit doen; een werknemer is per definitie iets anders als een klant. Sowieso zitten er hele verschillende beveiligingsaspecten aan de twee groepen (van welke klant sla je salarissen op?) en daarnaast wil je bepaalde mensen wél toegang geven tot bepaalde gegevens, zoals medewerker gegevens, en andere niet. En dat geldt ook voor klanten. Dus hou die vooral gescheiden. De enige overeenkomst tussen een klant en een medewerker is, dat ze allebei van dezelfde diersoort zijn. En dat is niet genoeg reden om ze in één tabel te pleuren .

Maar in essentie heeft Luc (en dus ook ik) gelijk, en is mijn advies een stuk strenger: stop met de huidige opzet, want die deugt niet. Begin met je in te lezen in het proces van Normaliseren (want daar scheelt het echt aan) (bijvoorbeeld in de Access cursus in de Handleidingen sectie) en ontwerp je tabellen opnieuw volgens op zijn minst normalisatie in de derde graad. Als je dat voor elkaar hebt, kunnen we verder kijken naar de db. Maar steek vooral geen tijd meer in het doorontwikkelen van dit model. Het loont de moeite niet.

 

[LucHeyndrickx]

Hangt er wat van af hoe je het zelf opbouwt .

Ik ga een voorbeeld geven waarbij een werknemer tegelijkertijd klant zou kunnen zijn:
Stel je bent een bouwfirma, met x aantal werknemers. Deze werknemers moet je uiteraard kunnen inzetten bij de werkzaamheden.
Maar deze werknemers kunnen eveneens klant worden door hun huis door hun eigen bedrijf te laten bouwen. Op dat ogenblik is die persoon zowel werknemer als klant (eventueel zelfs leverancier).
Maar je hebt wel gelijk dat je dan een tabel krijgt waar sommige velden niet gebruikt worden. Trouwens... niet elke klant heeft een BTW nummer, dus daar loopt het bij klanten ook al uit elkaar.

Hoe je de database opbouwt is uiteindelijk aan de programmeur, en hetgeen die (en de gebruiker) er mee wil bereiken.

 

[OctaFish]

Ik stel voor dat we ons beperken tot antwoord op de vraag; dit soort uitwijdingen leidt alleen maar af. En TS isal niet scheutig meer met informatie. Maar juist jouw voorbeeld is de ultieme verklaring om deze constructie dus nooit te gebruiken.

 

[NoellaG]

@ Luc: bij de opmerking

Hoe je de database opbouwt is uiteindelijk aan de programmeur

geeft ervaring me toch een paar rillingen. Het is niet voor nieks dat de volgend T-shirts populair zijn onder mijn collega's (zie bijlage):

 

[tonp60]

Sorry voor alle ophef. Ik ga me er proberen in te verdiepen.

 

[OctaFish]

Je hoeft je uiteraard nooit te verontschuldigen; databases maken is echt een specialisme. Een vák. En niet iedereen beheerst dat, en al helemaal niet als je weinig ervaring met databases hebt. Kortom: we hebben het allemaal moeten leren .