ID veranderen in record en gerelateerd record

[Wim Bongertman]

Beste mensen

 

Mijn vraag is de volgende. Ik heb een database met klanten. Deze hebben een uniek klantnummer (debiteurennummer) door middel van dit nummer is er een koppeling (relatie) gemaakt naar facturen. Stel dat ik deze debiteur een nieuw nummer geef dan vervalt de koppeling naar facturen. Ik wil dus in beide bestanden dit nummer tegelijk wijzigen om de koppeling te behouden. Wie kan mij helpen?

[AvD]

Dat kan met een scriptje en wat voorbereidend weerk: ga naar de klant, zet zijn ID in een global, definieer een relatie van die global naar Facturen, keer terug naar de klant; verander zijn ID, zet die nieuwe ID in een andere global, ga naar de eerste global, ga vandaaruit naar de gerelateerde facturen; vervang daar de klant ID's door die van de global. Maak de globals weer leeg.

[DJ_Lucv]

Misschien had je dit antwoord eigenlijk al wel verwacht TS maar wat je doet is dus totaal niet de bedoeling. Dat nummer is er om een klant uniek te maken, en dat hoeft dus nooit te veranderen. Zeker niet omdat de gebruiker van je systeem dat van plan is. Mijn vraag dus: waarom wil je dit gaan doen?

[AvD]

Mijn vraag dus: waarom wil je dit gaan doen?

Ik heb al heel wat systemen gezien waar dat toch wel gebeurt, DJ. Bijvoorbeeld in situaties waar meneer PK030124 zijn statuut van potentiële klant verliest omdat hij nu eindelijk een bestelling geplaatst heeft. Hij wordt dan K030124. Dit komt voor in zo goed als alle systemen waar een bedrijfsinformatisering verplicht wordt zich aan te passen aan bestaande coderingen die nog altijd in de boekhoudsystemen zitten of die op een andere werkplek het systeem ontsieren...

[DJ_Lucv]

Dan zit je systeem verkeerd in elkaar. Je maakt een apart veld met status: potentieel of klant. De code's die je geeft zijn misschien leuk om op je factuurtje te zetten maar zijn niet relevant om binnen een systeem te gebruiken.

[AvD]

DJ, je moet lezen wat er staat: dit komt voor bij alle bedrijfsautomatiseringen die zich moeten aanpassen aan bestaande systemen (en waar hele afdelingen steigeren als er iets aan hun bestaand systeem verandert). Dat dat niet goed is, weet ik ook wel. 't Zou maar mankeren...

[DJ_Lucv]

Ik zou nooit daarom voor een dergelijk systeem kiezen. Dan zou ik nog eerder iets als dit opzetten:

koppeltabel gekke nummers bestaande uit de velden:

fakenummer: dat nummer wat alle bedrijfsadministratiesystemen volgens AVD gebruiken

goed nummer: alleen het klantennummer

type klant: 1 voor actief, 2 voor passief of weet-ik-veel-wat

 

Je kunt dan dat fakenummer laten zien aan de gebruiken, eventueel zou je zelfs het invoeren via het fake nummer kunnen laten lopen. Van de velden goednummer en type klant maak je dan een calculatieveld die de juiste gegevens uit het fake nummer haalt.

[AvD]

fakenummer: dat nummer wat alle bedrijfsadministratiesystemen volgens AVD gebruiken

DJ toch, dat heb ik toch nérgens gezegd, dat alle bedrijfs-enz dat gebruiken. Er staat: "dit komt voor bij alle bedrijfsautomatiseringen die zich moeten aanpassen aan bestaande systemen".

 

Je hebt toch geleerd dat een betrekkelijke bijzin zonder voorafgaande komma restrictief is, en dat zo'n zin betekent: "enkel die bedrijven die...".

 

Maar je hebt gelijk dat die situatie niet ideaal is. Vraag is alleen wat de klant wil en hoeveel hij daarvoor wil betalen.

En nu aan het werk om Loeki de Leeuw te helpen. Die zal het nodig hebben! Ik heb zelden zo'n niveau-verschil gezien tussen vraag en antwoord !

[Wim Bongertman]

Grappig, je stelt een vraag en er ontstaat gelijk en hele discussie. Mijn vraag was verpakt in een voorbeeld om het te verduidelijken. Het werkelijke probleem zit hem in een bestand met z.g. e.a.n. codes (streepjes-code) welke gebruikt worden om bestanden aan elkaar te verbinden. Diverse leveranciers geven bestanden met daarin hun gehele assortiment. Iedereen gebruikt andere omschrijvingen en artikelnummers. Een gegeven is gelijk n.l. de e.a.n. code. Helaas zie je regelmatig dat een leverancier een fout maakt in deze code. Indien ik een artikel aanmaak in mijn verkoop bestand volgt er dus automatisch een koppeling met de in het inkoopbestand aanwezige artikelen die dezelfde e.a.n. code hebben. Als de eerste koppeling fout is omdat de leverancier de verkeerde code heeft meegezonden met zijn bestand, lijkt het later alsof er geen anderen inkopen bestand dezelfde e.a.n. code. Ik wil de foute later vervangen door een goede e.a.n. code en wel zowel de verkoop als inkoop bestanden tegelijk wijzigen. Met een global veld welke tijdelijk gebruikt wordt om een e.a.n. code in te parkeren lukt het niet. Immers zodra je de originele (gekoppelde) e.a.n. code in een van de bestanden wijzigd, ben je de koppeling kwijt en ontstaat er een situatie waarin de ontkoppelde record handmatig moeten worden opgezocht. Misschien heb ik zo mijn vraag verduidelijkt.

 

Beste mensen

 

Mijn vraag is de volgende. Ik heb een database met klanten. Deze hebben een uniek klantnummer (debiteurennummer) door middel van dit nummer is er een koppeling (relatie) gemaakt naar facturen. Stel dat ik deze debiteur een nieuw nummer geef dan vervalt de koppeling naar facturen. Ik wil dus in beide bestanden dit nummer tegelijk wijzigen om de koppeling te behouden. Wie kan mij helpen?

[AvD]

Dank voor de verduidelijking, maar dat was niet echt nodig: het principe blijft hetzelfde, en ook het eerste antwoord blijft gelden: een paar globals en een scriptje.

 

HTH

[Wim Bongertman]

Dank voor de verduidelijking, maar dat was niet echt nodig: het principe blijft hetzelfde, en ook het eerste antwoord blijft gelden: een paar globals en een scriptje.

 

HTH

 

Ik heb inmiddels de nodige uren besteed aan dit probleem, met enkele global fields en een paar scriptjes lukt het prima. Hartelijk dank voor de hulp

[DJ_Lucv]

Misschien dat je mijn post als flauw op gaat vatten, maar heb je wel voor een veilige transactie gezorgd? Lock je dus eerst op de een of andere manier alle records waarvan je de id's gaat wijzigen voor je dit doet? Anders zou je namelijk weleens problemen kunnen krijgen met je gegevens. Bijvoorbeeld omdat iemand tegelijkertijd een rekening invoerd die verbonden is aan de oude id.

[Wim Bongertman]

Misschien dat je mijn post als flauw op gaat vatten, maar heb je wel voor een veilige transactie gezorgd? Lock je dus eerst op de een of andere manier alle records waarvan je de id's gaat wijzigen voor je dit doet? Anders zou je namelijk weleens problemen kunnen krijgen met je gegevens. Bijvoorbeeld omdat iemand tegelijkertijd een rekening invoerd die verbonden is aan de oude id.

 

Natuurlijk, ik begrijp je opmerking. Mijn programma is overigens single user, dus hoef ik mij niet druk te maken over gegevens welke door meerdere mensen tegelijkertijd zouden kunnen worden gewijzigd. Overigens ben ik er wel achter dat het heel zinvol is om eerst eens goed te gaan nadenken over het opzetten van diverse tabellen en de benodigde gegevens. Later veranderen van gegevens (vooral die welke de koppelingen verzorgen) is erg lastig.