data wijzigt uit zichzelf

[Stardust]

Beste Groep,

 

Ik zit met een probleem dat m'n petje te boven gaat ...

 

Een databestand verzamelt allerlei gegevens aangaande kandidaten die eenexamen afgelegd hebben.

 

Elke kandidaat krijgt een uniek nummer dat bestaat uit een berekening van de veldwaarde ExamenDatum gevolgd door de waarde uit Dagnummer.

 

De dagnummer wordt bepaald aan de hand van de alfabetische volgorde der kandidaten op dezelfde examendag.

 

Door allerlei omstandigheden waren de nummers niet allemaal in orde, zodat we genoodzaakt waren hiervoro een oplossing te bedenken.

 

Vooraleer verder te gaan dien ik te zeggen dat het totaal uit ca 35000 bestaat.

 

Zodra we een kandidaat opzoeken in de database en we merken op dat deze zijn/haar examennummer niet conform is laten we een script lopen.

 

Dit script voert de volgende handelingen uit:

 

• Copy[select, "ExamenDatum"]
  Enter Find Mode[]
  Paste [select, No Style, "ExamenDatum"]
  Perform Find [Replace Found Set]
  Sort[Restore, No Dialog]
  Replace Contents[No Dialog, "DagNummer", "Serial Numbers"]

 

Alle examenkandidaten die op dezelfde dag examen gedaan hebben worden gevonden, gesorteerd, alfabetisch op naam en het dagnummer wordt vervangen gaande vanaf 01 en verhoogd met de waarde 1.

 

Zo ver zo goed ... tot enkele dagen later blijkt dat de dagnummers veranderd zijn

 

Het veld dagnummer is een 'Number' veld, Het veld ExamenNummer is een 'Calculation' veld gebaseerd op de examendatum en de waarde van het veld dagnummer maar geeft op zich geen problemen. Het is voornamelijk de veldwaarde van het veld dagnummer dat verandert.

 

Waarschijnlijk zit het probleem in het script maar ik snap niet waar en/of waarom

 

 

Een bijkomend probleem is dat ik nu een middel dien te vinden om alle records terug te voorzien van een uniek en geldig volgnummer, maar ik weet evenmin een manier hoe ik dat kan automatiseren want dit met de hand aanpassen voor 35.000 records is me nu net iets te veel van het goede

[JeanWM]

Wat ik niet graag zie in het kader van je uitleg is:

 

Copy[select, ...

en

Paste [select, ...

 

en zeker

Replace Contents[No Dialog.....

 

en dat je dat uitprobeert op een live toepassing en niet eerst op een copy.

 

Ik zou op recordniveau blijven met een calculatie ipv op found set niveau aanpassingen te doen.

 

Als je op recordniveau blijft, kun je met enkele bijkomende velden gemakkelijker volgen wat er gebeurt of dient te gebeuren, terwijl de bijkomende berekening(en) gemakkelijker kunnen aangepast worden.

 

Om te weten wáár het probleem zit zou een inzage op velddefinitie noodzakelijkzijn.

 

Mijn eerste idee gaat in de richting van een unstored waarde....

[Stardust]

Jean,

 

Ik begrijp volkomen je opmerkingen aangaande de bewerking op een live versie. Probleem is echter dat het eerst op) een copy getest is maar dat het niet opgevallen was dat na enige 'tijd' oudere aangepaste waarden in het 'number' field dagnummer veranderden.

 

Wat betreft de velddefinities die hier van tel zijn gaat het in feite enkel om het veld dagnummer, de andere velden vertonen geen problemen. Gezien dit slechts een 'number' field is, zonder enige optie, denk ik dat unstored hier niet van toepassing is.

 

Wat je andere opmerkingen betreft, ik zie niet goed in hoe ik dit op een andere wijze kan aanpassen. Ik heb immers alle records van een zelfde examendatum nodig, waarna ik ze sorteer op alfabetische volgorde op basis van de naam van de kandidaat. Uiteindelijk kan ik dan binnen deze groep de dagnummers aanpassen d.m.v. een replace opdracht. Ik zie niet het alternatief om dit te doen op record niveau

[JeanWM]

Even kijken of ik het kan volgen:

 

Elke kandidaat krijgt een uniek nummer ....

 

De dagnummer wordt bepaald aan de hand van de alfabetische volgorde der kandidaten op dezelfde examendag.

 

Elke kandidaat krijgt een uniek nummer dat bestaat uit een berekening van de veldwaarde ExamenDatum gevolgd door de waarde uit Dagnummer.

 

Zodra we een kandidaat opzoeken in de database en we merken op dat deze zijn/haar examennummer niet conform is laten we een script lopen.

 

Kan het zijn dat het nummer verandert omdat de alfabetische volgorde verandert, omdat je

Sort[Restore, No Dialog]

doet ?

 

Je nummers blijven niet uniek door het feit dat ze 'veranderlijk' zijn.

[Stardust]

Je kan volgen Jean

 

De wijzigingen hebben echter niets te maken met de sorteervolgorde, bvb. wanneer een dagnummer aangepast werd via het script. Enkele tijd later na het uitvoeren van verschillende handelingen binnen het bestand blijken de volgnummers (in het veld dagnummer) gewijzigd van bvb. 27 naar 13727. Het blijkt dat er telkenmale een ander getal voorgeplaatst is dan is dat bvb 137 en later 138 en wijzigen de dagnummers door de oorspronkelijke waarde voorafgegaan door dit nieuwe getal dat van weet ik waar komt

 

De sortering gebeurt altijd maar op de gevonden reeks records welke na de uitvoering van het script correct aangepast zijn.

[JeanWM]

Het is nog altijd een beetje vaag, waarschijnlijk door de afstand...

We proberen met zjn allen hier greep te krijgen op het geheel....

 

De dagnummer wordt bepaald aan de hand van de alfabetische volgorde der kandidaten op dezelfde examendag.

Hoe gaat dat in praktijk in z'n werk ¿

...en we merken op dat deze zijn/haar examennummer niet conform is...

Hoe moet die er uit zien ?

Een

... berekening van de veldwaarde ExamenDatum..

gevolgd door

...een bepaling aan de hand van de alfabetische volgorde der kandidaten op dezelfde examendag...

Wat moeten we ons daar bij voorstellen ?

Wordt de datum omgezet naar een numerieke waarde ?

Wat en hoe is de 'bepaling' ¿

[Stardust]

Jean,

 

Dit bestand heeft een lange geschiedenis ... Het is een samenraapsel van verschillende bestanden uit verschillende bronnen zoals lotus, dbf, wordperfect, en eveneens oude lijsten nog met de hand geschreven (!). Het hoeft geen betoog dat een dergelijk samenraapsel vol met fouten zit waarvan de meest voorkomende fouten zijn: onvolledige data, verkeerde data, enz...

 

Het gaat over ca 35000 mensen die een examen afgelegd hebben vanaf ca 1960 tot op vandaag en daarvoor een certificaat verkregen hebben (enigszins te vergelijken met een rijbewijs). Enige tijd geleden kreeg een verlichte geest het idee om een geldigheidsdatum op deze certificaten te kleven. Voortaan zouden deze certificaten nog slechts 5 jaar geldig zijn maar konden op aanvraag verlengd worden.

 

Om het nog ingewikkelder te maken bestaan er vier soorten van certificaten.

 

Onze werkwijze die we binnen een dag in elkaar hebben geflanst, bestaat er uit om aan iedereen van wie de vervaldatum van het certificaat nadert een brief toe te zenden teneinde hem/haar de mogelijkheid te bieden bedoelde titel te verlengen.

 

Dat werkt wonderwel allemaal redelijk goed, behoudens het in voorgaande post genoemde probleem.

 

Wat betreft de certificaat nummer dit is een samenstelling (calculation field) van de datum v/h examen gecombineerd met het dagnummer.

Ook dit geeft geen probleem. Het enige probleem is de dagnummer, dit is een gewoon numeriek (number) veld (zonder enige optie aangevinkt).

 

Voor elke examendag worden de kandidaten van dat examen gesorteerd op alafabetische volgorde en d.m.v. een 'replace' (Ctrl + =) wordt het volgnummer gewijzigd beginnend vanaf de waarde 001 verhoogd met stappen van 1. De eerste persoon uit het alafabet (bvb. Aapers Eddy) verkrijgt zo het dagnummer 001 en de laatste persoon (bvb. Zwijger Nicole) verkrijgt het nummer 123, wanneer er die bewuste examendag 123 personen het examen afgelegd hebben.

 

Daar we een heleboel records hebben waarvan er geen nummer werd toegewezen of een ander soort van nummer, dienden we een systeem te bedenken waarbij de nummer van het certificaat identiek bleef zonder te vervallen in nummers die hoger waren dan de waarde 1000, vandaar dat we voorgaand systeem bedacht hebben. Op deze wijze heeft ieder certificaat een uniek nummer bestaande uit de datum van het examen gevolgd door het dagnummer. Verder gaan op de voorbeelden van vorige alinea verkrijgt Aapers Eddy zo de certificaat nummer 19741012-001 en Zwijger Nicole het certificaat nummer 19741012-123 waarbij we er van uitgaan dat de examendatum 12 oktober 1974 was.

 

Het is dus niet het berekeningsveld 'Examendatum' dat in de fout gaat maar het veld 'dagnummer'. Zonder enige reden wijzigt de inhoud van dit veld van bvb 123 naar 137123.

Waarom begrijp ik niet, nogmaals het is een gewoon numeriek veld zonder enige optie aangevinkt in de velddefinities. De enige bewerking die er op gebeurt is de vervanging d.m.v. de replace functie (Ctrl + =) dit aan de hand van het genoemde script in mijn beginposting.

 

De reden waarom ons dit nog maar pas opgevallen is dat dit niet onmiddellijk gebeurt. Gedetailleerder uitgelegd, volgt hier een simulatie van een praktijkvoorbeeld.

 

Een bepaald certificaat dient verlengd te worden en wordt opgezocht in de database. Nu blijkt dat er geen dagnummer toegekend werd voor dit certificaat en gaan we het script 'aanpassing van dagnummers' uitvoeren.

Vervolgens worden alle records van dezelfde examendag als het te verlengen certificaat opgezocht vandaar die eerste scriptstappen Copy en Paste. Zodra deze records gevonden zijn worden ze gesorteerd op alfabetische volgorde op basis van de familienaam en voornamen. Als laatste stap wordt het veld 'dagnummer' voor al de gevonden (en gesorteerde) records gewijzigd d.m.v. de 'Replace' functie gaande van 001 te verhogen met telkenmale 1.

Dit werkt feilloos en na de uitvoering van het script hebben alle records een uniek certificaatnummer gebaseerd op de examendatum en het dagnummer.

 

Wanneer we na enige tijd terug in deze reeks terecht komen blijken de dagnummers plots andere waarden te bevatten. Het is dus enkel het veld 'dagnummer' dat voor problemen zorgt. Vanzelfsprekend wordt het veld 'certificaatnummer' beinvloed door dit fenomeen, maar hier ligt uiteraard het probleem niet want dit rekenveld doet zijn (of is het haar) werk naar behoren.

 

Oef ... ik hoop dat ik nu de situatie duidelijk geschets heb Maar nog meer kijk ik uit naar de oplossing

[Raven]

Zodra we een kandidaat opzoeken in de database en we merken op dat deze zijn/haar examennummer niet conform is laten we een script lopen.

 

Ok, dit is een schot in het duister, maar kan het volgende misschien gebeuren ?

1. je vindt een nonconforme kandidaat en laat het script lopen

2. 3 dagen later vind je opnieuw een nonconforme kandidaat, en dit van dezelfde datum als de vorige

3. het script loopt opnieuw en "overschrijft" de vorige seriële waardes. Je gaat dus opnieuw een dagnummer toekennen aan alle records die eigenlijk 3 dagen voordien al 's volledig opnieuw genummerd zijn.

 

Ben eigenlijk al een hele tijd niet meer actief met Filemaker bezig, maar misschien dat dit toch iets opbrengt

[Stardust]

1. je vindt een nonconforme kandidaat en laat het script lopen

2. 3 dagen later vind je opnieuw een nonconforme kandidaat, en dit van dezelfde datum als de vorige

3. het script loopt opnieuw en "overschrijft" de vorige seriële waardes. Je gaat dus opnieuw een dagnummer toekennen aan alle records die eigenlijk 3 dagen voordien al 's volledig opnieuw genummerd zijn.

 

Raven,

 

dit gebeurt inderdaad, hoewel het de bedoeling is dat het Replace commando op het einde v/h script de inhoud van dagnummer wijzigt en niet aanpast. Op zich maakt dit dus niet veel uit want het aantal kandidaten op de gezochte examendag blijven steeds even groot en dus dient de nummering ook steeds hetzelfde te zijn.

 

[JeanWM]

Dat ik wat 'doorduw' op het hoe en waarom en waar en wanneer is omdat we hier met enkelen proberen om je probleem te reproduceren.

 

Het is opgenomen in onze reeks 'eigenaardigheden die goed om weten zijn' (lokaal klinkt het wel anders, maar dit is de beste vertaling waar ik kan opkomen )

 

Afwachten of we het kunnen vinden....

[Peter Wagemans]

Stardust, je kan best een test inbouwen op de gevonden set.

Stel dat je om 1 of andere reden niets zou vinden, dan wordt de hele tabel gereplaced. Wat je niet echt wil...

 

- Set ErrorCapture On

- If [status ( CurrentError ) = 0] -> doe je ding

[Stardust]

Dat ik wat 'doorduw' op het hoe en waarom en waar en wanneer is omdat we hier met enkelen proberen om je probleem te reproduceren.

 

Dat doorduwen is héél begrijpelijk ... soms is het héél moeilijk om een probleem te begrijpen, analyse is de hoeksteen van programmeren of ben ik verkeerd ?

 

Stel dat je om 1 of andere reden niets zou vinden, dan wordt de hele tabel gereplaced

 

Peter,

 

Je hebt gelijk en anderzijds ook weer niet

 

Nu begeef ik me op glad ijs ... maar we gaan het script alleen maar activeren wanneer we effectief een geldige examendatum vinden.

 

Maar alleszins, onder het motto "baat het niet, schaadt het niet" is het alleszins een goed advies!!

[Jeroen Aarts]

Domme vraag wellicht, maar het script - of een andere - is toevallig niet ingesteld als uit te voeren bij het openen van het bestand?

 

Het lijkt me d'r op dat met je script zelf niets mis is, buiten de opmerkingen uit de eerste post van Jean.

[Stardust]

Jeroen,

 

Neen, het script wordt pas opgestart wanneer men merkt dat er geen dagnummer of een verkeerd dagnummer ingevuld is.

 

Ik heb er vandaag ook nog de ganse dag met bezig geweest zonder soelaas ... het blijft een raadsel voor me

 

Uiteindelijk zal er me niet veel meer resten dan het bestand vanaf 0 terug op te bouwen. Ik kan me niet van de indruk ontdoen dat er iets mis is met het bestand zelf, zonder, buiten dit euvel, er iets van te merken. Alleen bij samengebruik durft het soms eens kuren te vertonen.

 

Weldra echter behoort dit (hopelijk) allemaal tot het verleden, na een jaar wachttijd heb ik eindelijk Filemaker Server 8.0 ontvangen (aan de overheid gaat dit nu eenmaal niet zo snel), helaas was men vergeten om er de client versies bij te bestellen

 

Dit verklaart eveneens waarom ik zo lang aan het aarzelen ben om vanaf 0 te beginnen, het lijkt me interessanter dit pas vanaf v8.0 te doen.

 

Ondertussen heb ik een andere (voorlopige) oplossing toegepast waardoor ik toch ergens een uniek certificaatnummer met kan genereren. Dit neemt niet weg dat ik nog steeds benieuwd ben naar de oplossing v/h probleem

[JeanWM]

Alleen bij samengebruik durft het soms eens kuren te vertonen.

 

Ik herinner het mij niet meer (lees, geen zin om het op te zoeken ), werk je via server of peer to peer ?

[Stardust]

Jean,

 

Wij werken via server, niet onmiddellijk de juiste manier maar eindelijk na jaren gezeur eindelijk de FM Server gekregen ... nu nog wachten op de clients

[JeanWM]

Ne menuut mijn goede vriend:

 

Draai je FM 6 op Filemaker Server 8.0

 

..of mis ik weer iets, wat niet de eerste keer zal zijn...

[Stardust]

..of mis ik weer iets, wat niet de eerste keer zal zijn...

 

Jean,

 

Je mist niets ... het is mijn schuld!

 

Wij draaien momenteel nog geen server editie daar we (helaas) nog steeds niet over de geschikte client versies beschikken. Ter vollediging, 4 FM 6.04 clients en dit allemaal onder Windows XP Pro - SP2.

 

Voorlopig redden we ons nog steeds met FM6 zonder Server Edition waardoor de bestanden via de server ter beschikking worden gesteld aan de andere clients. Vertel me aub niet dat dit de slechte wijze is, dat weet ik maar we hebben jaren moeten roeien met de riemen die we hebben/hadden.

 

Vooraleer iemand nu gaat zeggen dat dit de oorzaak is van mijn hierboven omschreven probleem, dien ik te antwoorden dat dit bestand al bijna 2 jaar draait en dat het probleem zich maar de laatste weken is beginnen manifesteren.

[JeanWM]

.... Vertel me aub niet dat dit de slechte wijze is...

 

Waarom zou ik dat zeggen ?

Iedereen (moet) werk(t)en met de ter beschikking gestel(hebben)de tools.

Van mij ga je nooit horen dat je moet upgraden naar een andere versie of je zou iets willen bereiken dt echt niet anders kan dan...

 

Ik had een vaag vermoeden dat je niet op de server snelweg zat, maar wilde zeker weten. Dan zetten we de trial bestanden ook niet op ons netwerk maar op de p/p sectie.

 

We hebben 36000+ records aangemaakt, het script dat je gebruikt, de sortering enz. Maar nada tot nu toe.

In alle eerlijkheid moetik wel zegen dat ik het geheel nog niet zelf nagekeken heb....

(ook) Examentijd hier.....

[Stardust]

We hebben 36000+ records aangemaakt, het script dat je gebruikt, de sortering enz. Maar nada tot nu toe.

 

Wat dan ook mijn vermoeden bevestigt dat er iets loos is met het bestand zelf ... Alleszins ga ik er volgende week tegenaan om dit bestand vanaf 0 terug op te bouwen. Ik heb een soortgelijk script draaien in een ander bestand en daar geeft het evenmin problemen.

 

Mijn enigste verklaring is tot hiertoe ... het bestand is beschadigd