Unieke volgnummers aanmaken in multi-user setting

[Marsau]

Beste mensen,

 

Vandaag geconfronteerd met een interessant probleem, waarover ik mij verwonder dat we het niet veel vaker tegenkomen. Bij het aanmaken van records in een multi-user FMS-setting komt het voor dat er dubbele volgnummers worden uitgegeven, indien verschillende gebruikers vrijwel tegelijkertijd een nieuwe record aanmaken. Dit is een groot probleem als de volgnummers uniek moeten zijn. Uitwijken naar UUID is niet mogelijk: het is ook van belang dat de unieke code als volgnummer herkenbaar is.

 

Op dit moment gebruik ik een voor de betreffende tabel een relatie met dezelfde tabel, waarbij via het volgnummer met ALLE records wordt gerelateerd. Via een auto-enter formule (max(Alle_records::volgnr) + 1) wordt het nieuwe nummer gecalculeerd.

 

Dit werkt dus niet. Als we "gelijktijdig" (absoluut gelijktijdig zal het nooit zijn) records aanmaken, krijgen we duplicaten. Inmiddels van alles geprobeerd: het probleem blijft.

 

Any ideas?

[Felix]

.

5 oktober 2015 aangepast door Gast

[SuperWimmie]

Logisch dat het fout gaat. (tenminste, dat idee heb ik...)

 

Je berekent een hoogste waarde op basis van ongeveer alle records die er in de Filemaker database aanwezig zijn, over verschillende tabellen, en dat kost tijd.

De functie Max is geen snelle jongen.

Als intussen een andere gebruiker dezelfde berekening start, kan het zijn dat de push-update van de server het werkstation nog niet heeft bereikt, terwijl de berekening al in volle gang is.

Gebruiker 2 is mogelijk al het nieuwe record voorbij van gebruiker 1.

 

Heb je het al geprobeerd met het opslaan van een centraal volgnummer, die een gebruiker vervolgens ééntje ophoogt en direct weer opslaat?

Ik hou voor elk volgnummer een aparte tabel bij met liefst maar 1 veld. Dit maakt het totaal onafhankelijk van andere tabellen (ivm. onnodige record locking) en het werkt razend snel.

Middels een tweede veldje haal ik de gein uit deze te muteren alvorens de oude waarde uit te lezen. Op die manier wordt eerst de boel op slot gezet, voordat er gelezen wordt.

Degene die dan aan de beurt is, is gegarandeerd voorzien van een uniek nummer.

 

Mocht nummer twee zich aanmelden, dan stuit deze op een record lock. Dat is af te vangen via errors en nadat het record is vrijgegeven doe je daar hetzelfde om een uniek nummer te krijgen.

 

Automatische nummering van Filemaker: ik gebruik ze niet, omdat ik gescheiden van productieomgevingen ontwikkel.

Bij updates zijn die volgnummers moet je speciaal zaken programmeren om de loop van de nummers goed te krijgen.

Ontwikkel je in een productie omgeving, dan zouden de Filemaker nummers gebruikt kunnen worden.

[Felix]

.

5 oktober 2015 aangepast door Gast

[SuperWimmie]

@felix,

 

Klopt, maar dat houdt ook weer in dat je daar velden voor moet hebben. Als je ze dan toch hebt...

 

Maar laat Marsau even reageren hoe hij het wil hebben, dan zorgen we er hier op het forum wel voor dat het werkt

[Felix]

.

5 oktober 2015 aangepast door Gast

[menno]

Dit zijn altijd leuke problemen, waar iedereen zijn eigen problemen tegenkomt. Ik gebruik voor de interne "uniciteit" altijd een UUID, die ik genereer uit het serienummer en de aanmaaktijdstempel van de huidige server en de persistantID/NIC. Dat laatste lijkt onnodig ingewikkeld, maar zorgt dat ik bij een conversie nooit een teller hoef te updaten, echt helemaal nooit. De PK/FK koppelingen zijn altijd op deze ID's gebaseerd.

 

Voor de de zogenaamde "UserID" heb ik een aparte tabel waar ik per werkmaatschappij/hoofdtabel een volgnummer bijhoud. Bij het aanmaken óf definitief maken van een record (bestelling, offerte, order, factuur, begroting, project, bijeenkomst, brief, activiteit, agenda-item, etc. etc) lock ik het teller-record (indien mogelijk, anders wachten tot dat wél kan), keer een nieuw nummer uit, leg dat vast en geef dat terug aan het "object" dat daar om vraagt. Zo heb ik voor bijvoorbeeld facturen, keurig opeenvolgende nummers die ik niet op de een of andere manier hoef te "updaten" bij een conversie én alles is uniek.

 

Ik heb wel eens suggesties gezien om de "Max" van een nummer op te vragen, daar één bij op te tellen en die te gebruiken, maar dat is (weet ik uit ervaring) een goed recept om niet unieke nummers te krijgen.

 

Dus kort gezegd: houdt een unieke "teller" bij in de vorm van een UUID of gewoon een FM-volgnummer of iets wat op die manier werkt, waar je dan intern alles mee koppelt en houdt daarnaast voor de gebruiker een "eigen" volgnummer bij, waarbij je achtereenvolgens "lockt", "fouten-checkt", "uitkeert", "opneemt" en "vrijgeeft". Alle andere methoden geven in een multi-user-omgeving op enig moment beslist problemen.

[SuperWimmie]

PS, dat van die velden begrijp ik niet

 

@Felix: Als je een productie database wilt updaten, dan exporteer je alle data, dat is inclusief de waarde van de hoogste volgnummers. Dus ja, die kan je uitlezen, maar die moet je ook ergens in een veld kwijt.

 

@ Menno: er zijn goede redenen voor veel kortere unieke nummers, zoals gebruik van barcodes, of rapportages die kortere kolommen nodig hebben om unieke zaken snel te herkennen.

Korte codes zijn soms erg praktisch.

[menno]

@ Menno: er zijn goede redenen voor veel kortere unieke nummers

Ja exact en daarvoor is dan de "UserID", dat kan een artikelnummer zijn of wat dan ook wat de gebruiker handig vindt. Intern gebruik je jouw eigen unieke "nummering", waar de gebruiker met zijn vingers van af blijft en zelfs helemaal niet ziet, maar onwetend daarover wél gebruikt. Dus op de manier zoals ik hem hiervoor heb omschreven.

[hans erik]

Ik vind die UUID erg mooi en ik gebruik ze ook steeds meer, maar voor de standaard primary key geef ik toch de voorkeur aan een volgnummer (waarbij ik overigenbs altijd een tekstveld gebruik, met voorloopnullen, dus bijv. 00291801). Twee redenen:

1. ik werk veel met lijstjes bij het samenstellen van keuzelijsten en selecties, en dan is zo'n lijst met UUID erg onoverzichtelijk en ook onhandig omdat er in een UUID altijd streepjes zitten.

2. Vroeg of laat meer je een keer kijken of er ergens een nummer ontbreekt.

 

Ik gebruik de UUID dus vooral voor synchronisatie.

 

Wat betreft de vraag van het topic: altijd gewoon de ingebouwde nummering van FileMaker gebruiken, tenzij je een heel goede reden hebt om ervan af te wijken.

 

En ik kan me voorstellen dat je records uit verschillende tabellen van een nummer in één reeks wilt voorzien. Dus bijv. je hebt twee tabellen met elk een volgnummer maar volgnumemrs in de ene tabel mogen niet in de andere voorkomen vice versa. In dat geval moet je een extra tabel inrichtenwaarin je de nummers genereert volgens de nummering van FileMaker.

Maak je een record in een van beide tabellen aan, dan maak je eerst een nieuw record in de nummertable, en dat nummer gebruik je.

 

HE

[Marsau]

Hartelijk dank voor al jullie reacties.. Heel erg leerzaam!

 

De (Max + 1) route is dus geen handige oplossing in een drukgebruikte multi-super setting.

 

De getrapte benadering met een UUID en een apart volgnummer voor herkenbaarheid vind ik charmant - en ik realiseer mij dat ik dit ook wel op deze wijze heb toegepast, en dan met name om onderscheid te maken tussen 'concept' en definitieve records.

Maar het is een beetje overkill voor dit specifieke geval: we moeten direct over een herkenbaar volgnummer beschikken. En uniciteit is een must.

 

Vind het goed om te vernemen dat de auto-nummering van FM zo betrouwbaar werkt. Ik dacht daar namelijk eerder wat problemen mee ondervonden te hebben, maar wellicht berust dat dan op een vergissing.