Fortløbende numre

Det er hvad man må betegne som et klassisk spørgsmål....
Problemet er at opdateringen skal ske på serveren, ellers risikere man at samme nummer tildeles flere doc.

Jeg har lavet en løsning hvor en agent hver 5 min opdaterer. Da det er en agent kører den sekventielt og løser problemet. Agenten tager mad value fra et view.

Med denne løsning har du dog det problem at nummeret ikke påføres med det samme. Tror du dette kunne være en løsning for dit problem.

MvHans

der skulle lige ha' stået "max value" og ikke " mad value"..... ;o)

Ja, har set spørgsmålet mange steder på nettet, og kan ikke forstå at det er så svært for Lotus at lave fortløbende numre - det er jo den nemmeste opgave i alle andre systemer...

Men er den forslåede løsning i http://www.eksperten.dk/spm/402639 ikke brugbar?

Hvorfor kan den kun finde ud af at tælle til 2?

Jeg må lige tænke . .  .

Ja, det er mig der lavede koden. Glemte at skrive at den første kolonne i Count view'et skulle sorteres i faldende orden (Descending). Undskyld.

Det kunne jo forklare 2,2,2,2 (lol)

kaspertm> Kan jo egentlig godt se logikken i at det skal være descending... det kunne jeg bare ikke lige selv nå frem til... :)

Det ser ud til at virke perfekt nu. Eneste problem er vel hvis man sletter det sidste nummer, så kan det blive oprettet igen - det må man jo så bare lade være med...

Tak for hjælpen! Smid nogle svar, så fordeler jeg nogle point :)

>>yeager: Notes understøtter ikke fortløbne numre umiddelbart fordi det er et distruberet system. Det er jo ikke til at se hvad nummer et nyt dokument skal have når man arberjder på en lokal replika uden adgang til serveren.
>> Løsningen er følgende: Opret en ny formular med et nummerisk felt indeholdende første nummere i din nummer serie.
De dokumenter der skal have nummer tilført, må have kode i QuerySave til at håndtere dette numer, f.eks. Doc.NummerFelt = SerNum, hvor SerNum bør være en central funktion.
I SerNum gør du følgende
Diverse dim'er, bla. SaveOK , RetryTimes as integer
sæt Doc = View.GetDocumentByUNID(<din formular m. nummerfelt>)
SaveOK = False
While not SaveOK
Nr = Doc.NrFelt(0) + 1
Doc.NrFelt = Nr
SaveOK = Doc.Save
If SaveOK = False
RetryTimes = RetryTimes +1
If RetryTimes = 20 Then ExitFunction
set Doc = nothing
sæt Doc = View.GetDocumentByUNID(<din formular m. nummerfelt>)
wend
SerNum = Nr
end function

nå det var jeg vist lidt for længe om at få skrevet :-)

cdelicht> Nu forvirrer du jo bare :-) - er det en bedre løsning, anyone?

Bedre: ?
Sikekr: Jep. Bullet proof. Bruger den i adskillige systemer hos forskellige kunder og internt. Har aldrig gevet problemer!

Man kan nemlig også håndtere loikale replika ved kun at tildele numre når basen er på serveren! Cool lille feature ;-)

Ok, kan du forklare hvad den præcis gør anderledes end den anden?

Jeg vil ikke have point for den minimale indsats!

Cdelicht; Roger, kan du hurtigt ridse ned i ord hvad din QuerySave gør. Jeg vil da overveje om din kode er bedre end mit agent system (der trods alt virker omend med forsinkelse)

Hygge

QS i meget forenklet udgave:
bla bla bla
Doc.NummerFelt = SerNum
bla bla bla

Bemærk lige at ovenstående SerNum beskrivelse også er noget forenklet - mere en principskitse.

Det er vel ikke Doc.NummerFelt = SerNum der er interessant, men hvordan SerNum-værdien tildeles, eller hvad?

look above!

der er ikke meget kode i QS -det ligger centralt.
Faktisk ligger hele nummer systemet central da jeg arbejder med mange forskelige nummer serier.

Central = egen db

thomas>Den løsning jeg har givet dig, bruger jeg i en database for vores revisionsafdeling uden problemer. Teoretisk kan der dog opstå problemer hvis en bruger laver et nyt dokument på en lokal replika, som cdelicht er inde på. Har dine brugere behov for det?
cdelicht> Opererer du med to formularer, en til at holde styr på numrene og en til de dokumenter, der skal nummereres? Hvis det er tilfældet, gemmer du så alle numrene i et dokument eller et dokument pr. nummer?

kaspertm> Databasen jeg skal bruge det på, bliver kun kørt på serveren - aldrig på en lokal replika. Så jeg kan godt bruge din kode uden problemer?

Ja, det kan du godt.

Ok, endnu engang tak for hjælpen, cdelicht får også lidt af pointene for forsøget.

Jeg ville ønske jeg lige havde det forkromede overblik over cdlicht's løsning... men jeg må hellere lade det ligge.

Ja, jeg ville ønske jeg forstod hvorfor lotus notes skal være så besværligt, men det må jeg også hellere lade ligge :-)

En formular pr. nummerserie!
Ja, min løsning er lidt mere kompleks, men gør det ikke sværere for dig selv end nødvendigt ;-)

Notes er IKKE besværlig, omend der er nogen bumiddelbare begrænsninger. Det er bare ikke MS!
Faktisk er Notes udviklere nogen af de mest kreative udviklere der findes, fordi nogen ting bare ikke er lige til i Notes.

Det med at tingene ikke er lige til i Notes, kan jeg godt nikke genkendende til. Men o man bliver kreativ eller pisseirriteret af det, det kan jeg ikke svare på. :)

Jeg har selv for nogle år siden prøvet cdelichts løsning. Det gode ved den er at den faktisk er meget præcis. Mens kaspertms løsning er den "gængse" gamle måde at gøre det på, så kan man faktisk fremprovokere dupletter ved at gemme mange dokumenter samtidig. cdelichts løsning tager højde for det ved at udnytte Notes safe-conflict håndtering.

ideen er som følger:
få adgang til serienummerdokumentet
inkrementer serienummeret
forsøg at gemme dokumentet
hvis det lykkes, tildel dokumentet der skal gemmes det godkendte serienummer.
hvis det ikke lykkedes, start forfra

cdelicht laver en tæller på 20 forsøg. Hvis det ikke lykkedes inden 20 forsøg tildeles ingen nummer. Nummeres skal derefter tildeles ved en anden lejlighed.

I ND6 kan man arbejde med dokumentlåse, som gør dette på den rigtige måde. men jeg har hørt nogle sige at dokumentlåse ikke er helt sikre endnu.

> thomas > ja, det kan være du synes det er besværligt, men hvis man tvang andre systemer at kunne gøre det samme som Notes, så ville disse komme frem med helt lignende løsninger. Nu har jeg arbejdet med Notes siden '93, og jeg LOVER dig jeg syntes det var besværligt, både administrationsmæssigt og programmeringsmæssigt. Men det er meget sjældent at de har taget fejl, de folk fra Lotus. Lige fra starten (V1-V2) har der være taget højde for mange af de problemer, som MS først nu er ved at opdage at de har. Og for det meste er der en fornuftig forklaring på hvorfor noget ikke kan lade sig gøre "nemt". Hav lidt tålmodighed og vær åben over for de muligheder systemet giver dig, så vil du opdage at dette er en meget bred infrastruktur, som kan rumme mange af de opgaver der skal løses, vel og mærke med selv samme produkt/platform.
//Jörg

jogii> Du har formentlig ret i, at ms-programmerne langt fra kan det som Notes kan. Men jeg forstår bare ikke, hvorfor helt basale ting som autonummerering ikke er indbygget i Lotus Notes. I f.eks. MS-SQL (eller en hvilken som helst anden database) er det jo en indbygget funktion, at databasen tildeler et autonummer-felt en værdi, når der oprettes en record.
Bortset fra det, kan jeg sagtens se hvad det smarte ved notes er - synes dog stadig, at tingene kunne gøres smartere. Men jeg vænner mig jo nok til det :)

Thomas>>
Der er skam autonummering i Lotus Notes, og det har der været fra start af.

Alle dokumenter bliver tildelt et nummer, når de bliver oprettet. Og Notes er tilmed så smart at dette nummer altid er unikt og derfor kan bruges til entydig identifikation af ethvert Notes-dokument (herunder design elementer).

At alle dokumenter har et unikt nummer er faktisk årsagen til at replikering kan fungere. Og Notes' replikering er jo grundstenen i det distribuerede miljø som jo er Notes' styke.

Brugerne kan arbejde  med Notes-databaser placeret på servere overalt i verdenen sågar lokalt og alligevel vil alle brugere kunne se de udarbejde dokumenter inden for en overskuelig tidshorisont (alt efter hvorledes replikeringen er sat op).

Og i et sådan distribueret miljø, er det jo nonsens at arbejde med fortløbende numre. For hvordan skulle en applikation der er spredt ud over hele verdenen kunne nummere fortløbende?

Nu kan mennesker jo noget bedre håndtere fortløbende numre i decimal systemet end Notes' unik ids i HEX, og det er også årsagen til at løsninger som de ovenfor beskrevne bliver lavet - og fred være med det.

Men husk Notes' store styrke er det distribuerede miljø, hvor sådanne numre ikke giver mening. Så derfor er det bestemt ikke en basal ting der mangler i Notes. Hvis der blev indbygget en funktion til autonummerering så ville den funktion jo samtidigt kræver at replikering af den pågældende base blev disablet.

pr0gm4n> Tak for forklaringen :)

Hvordan får jeg i øvrigt koden i Querysave til kun at blive udført, hvis dokumentet oprettes og ikke når det redigeres?

Altså noget lign:

Dim uidoc As NotesUIDocument
If uidoc.IsNewDoc Then ...

i LotusScript, men det skal ved også være i Formula?

Går udfra jeg skal bruge @If(@IsNewDoc;  men hvordan sætter jeg det ind i:

_number:=@Subset(@DbColumn( "" : "NoCache" ; "" ; "Count" ; 1 );1);
FIELD ID := @If(@IsError(_number) | _number="";1;_number+1);
@Success

Har lavet dette, så nu håber jeg det er rigtigt - det ser ud til at virke:

_number:=@Subset(@DbColumn( "" : "NoCache" ; "" ; "Count" ; 1 );1);
newID := @If(@IsError(_number) | _number="";1;_number+1);
FIELD ID := @If(@IsNewDoc;newID;ID);
@Success

halleluja - jeg tror ski' at jeg er ved at se lyset 8^)

Jörg's forklaring var vist nok lige det overblik jeg manglede.

Nu skal jeg bare lige overveje om det kan svare sig at lave min agentbaserede løsning om.
Tak Jörg!

Du skal ikke lave tildelingen af nummeret under åbningen af dokumentet (QueryOpen). Hvis nu brugeren fortryder oprettelsen, så er tildelingen forgæves. Tildelingen "committes" først når dokumentet bliver gemt. Når brugeren er flere minutter om at gemme, så vil andre personer få tildelt det samme nummer, sålænge dokumenterne ikke er gemt.
Du SKAL håndtere tildelingen i QS. Start med at spørge om dokumentet i forvejen har et serienummer. Hvis ikke, så tildel, ellers spring over.
//Jörg

jogii> Jeg tildeler det jo netop ikke i QueryOpen, men i QuerySave. Og jeg tjekker også om det er et dokument, som netop er oprettet eller et der bliver redigeret.

Undskyld. Der overså jeg. Det var bare brugen af @IsNewdoc der irriterede mig.
Jeg vil heller checke
@If(ID=""; @Return(""); @Success);
FIELD ID := <code>

Kan man da ikke regne med @IsNewDoc? Ellers kan jeg da ikke se, hvad forskellen skulle være?

Jeg har altid lagt denne kode ind i selve ID-feltet som et computed felt
@If( @IsNewdoc & @IsDocBeingSaved; @Success; @Return(ID));
<kode>
Så kan man bruge QS-eventen til andre formål.

@IsNewDoc virker fint. Man kan dog komme ud for situationer hvor man får oprettet dokumenter i forvejen (f.eks. via LotusScript), så vil @IsNewDoc ikke fange hændelsen.

Jeg glemte at fortælle vedr. cdelichts løsning, dengang jeg lavede den til Domino 4.6.1 i en web-løsning, så gik processor CPU op i 100% ved samtidig gemning af mange dokumenter, da multiple Web-QS-agenter tilsyneladende gik berserk og prøvede alt for ivrig at få lov. Jeg tror det var nødvendig at indsætte en kunstig pause efter et mislykket forsøg.