JeanWM Posted April 29, 2004 Posted April 29, 2004 We zitten in een interessante (althans voor ons) discussie, en de meningen lopen nogal (ver) uiteen.... Nadat een record (of verschillende) werden geprint, wordt er een controle gedaan op wat werd afgeprint. Als dat goed is, dienen de afgeprinte records 'gelocked' te worden....er mogen géén veranderingen meer gedaan worden aan/in de records. We zouden graag de hoe en de pro's en con's weten van de mogelijke toe te passen methodes om dat te doen. Quote
Rony Rabijns Posted April 29, 2004 Posted April 29, 2004 Jean, ik neem aan dat je het record wil vlaggen via een scriptstap SetField(nVlag)=1 bvb ? op de velden op je layout zet je een Calculated Validation = de validatie is true als de vlag op 0 staat, maw not(nVlag) nadeel : je moet die calculatie opnemen in ieder veld op je layout voordeel : betrouwbaar Quote
Dr_Flash Posted April 29, 2004 Posted April 29, 2004 Kun je in dit geval niet iets met de Get(RecordModificationCount)-functie? Parkeren in een globaaltje en in je printscript opnemen dat die na printen niet meer groter mag worden? Beetje freewheelen hoor Quote
Sanne Posted April 29, 2004 Posted April 29, 2004 We zouden graag de hoe en de pro's en con's weten van de mogelijke toe te passen methodes om dat te doen. Ik zou met grote stelligheid je de record-locking met behulp van een wachtwoord aanbevelen. Heb het zelf reeds meerdere malen toegepast en het werkt zeer redelijk en zeker robuust. Onlangs nog een draadje over geweest met Wim: http://www.clarify.net/viewtopic.php?t=1463 Je bent bekend met deze methode? Of zullen we het met een stappenplannetje doen? Het grote voordeel is natuurlijk dat je niet op ELK veld een validatie hoeft te zetten ... Quote
Rony Rabijns Posted April 29, 2004 Posted April 29, 2004 Kun je in dit geval niet iets met de Get(RecordModificationCount)-functie? Parkeren in een globaaltje en in je printscript opnemen dat die na printen niet meer groter mag worden? Beetje freewheelen hoor Doc, deze optie had ik ook als eerste bekeken, maar daar liep ik vrij snel mee tegen de lamp. Ik kon namelijk die "teller" niet echt onder controle houden, want die verhoogt namelijk bij iedere actie op een veld. En er waren in mijn "testopstelling" situaties dat ik eigenlijk niets deed en toch ging die teller omhoog. Vandaar dat ik die naar de prullenbak verwezen heb. Ik ben op het einde van deze draad, envenzeer als Jean, benieuwd wat er uit de bus gaat komen. Quote
Rony Rabijns Posted April 29, 2004 Posted April 29, 2004 Ik zou met grote stelligheid je de record-locking met behulp van een wachtwoord aanbevelen. Heb het zelf reeds meerdere malen toegepast en het werkt zeer redelijk en zeker robuust. Sanne, maar dan geef je de eindgebruiker toegang tot het wachtwoordbeheer ... of niet ? Quote
Dr_Flash Posted April 29, 2004 Posted April 29, 2004 ik begrijp het verkeerd. Die controle wordt met de hand gedaan Jean? Dan wordt het denk ik een stuk makkelijker. Ik dacht dat je automatisch wilde locken zodra een record geprint werd.... Sanne, hoe heb je dat met wachtwoorden in gedachten eigenlijk? Je zult dan records verschillende statussen moeten geven waar de privileges-unit mee kan omgaan.... Dit ging toch over FMP5 Jean? Kon dat toen al? Quote
Dr_Flash Posted April 29, 2004 Posted April 29, 2004 Doc, deze optie had ik ook als eerste bekeken, maar daar liep ik vrij snel mee tegen de lamp. Ik kon namelijk die "teller" niet echt onder controle houden, want die verhoogt namelijk bij iedere actie op een veld. En er waren in mijn "testopstelling" situaties dat ik eigenlijk niets deed en toch ging die teller omhoog. Toch, Rony, heb ik ook weleens solutions gezien waarbij waarden eerst naar hartelust veranderd werden, en dan met een knop en een script de invoer vastgelegd werd. Dan zou je dus in dat script op kunnen nemen dat dat niet meer mag zodra er een vlag aanstaat. Ik zal eens gaan testen met die RecModCount, eens kijken waar die allemaal van toeneemt. Ik denk dat dit echt wel een bewandelbaar pad is hoor... Quote
Sanne Posted April 29, 2004 Posted April 29, 2004 Sanne, maar dan geef je de eindgebruiker toegang tot het wachtwoordbeheer ... of niet ? Ik volg je niet helemaal. Je hebt toch een hoofdwachtwoord (= "God") en een gebruikers wachtwoord (= "Pietje")? Zo niet, dan zou ik die in elk geval aanbevelen. En de edit-record-limiter zet je toch op het gebruikerswachtwoord ("Pietje")? En de voorwaarde waaronder een record nog ge-edit mag worden is wanneer het door jouw besproken vlaggetje nog niet omgezet is. Recordlocking is mogelijk vanaf versie 5.5. Dat is het absolute minimum om van die functionaliteit gebruik te maken. Oh, wacht, ik snap: in de titel van deze post staat "5". Uh, in dat geval zou ik dan toch echt aanbevelen om naar 5.5 te gaan ... Een andere methode om in 5 aan record-locking te doen, is nog steeds met wachtwoorden en toegangprivileges. Je maakt voor elke scherm 2 layouts aan: eentje waarin ge-edit mag worden, en eentje waar dat niet meer kan (te regelen in toegangprivileges met die bolletjes). Belangrijk nadeel is dat je de gehele navigatie moet overnemen: het statuspaneel moet je volledig uitschakelen en locken om te vermijden dat je met de klapper of met control-toetsen nog naar een ander record gaat. Afhankelijk van je vlaggetje ga je dan naar de ene layout of naar de andere layout. Jep: ik heb het in het verleden gemaakt en WEET hoeveel werk dat is. Vandaar nogmaals: 5.5! Quote
Rony Rabijns Posted April 29, 2004 Posted April 29, 2004 Doc, deze optie had ik ook als eerste bekeken, maar daar liep ik vrij snel mee tegen de lamp. Ik kon namelijk die "teller" niet echt onder controle houden, want die verhoogt namelijk bij iedere actie op een veld. En er waren in mijn "testopstelling" situaties dat ik eigenlijk niets deed en toch ging die teller omhoog. Toch, Rony, heb ik ook weleens solutions gezien waarbij waarden eerst naar hartelust veranderd werden, en dan met een knop en een script de invoer vastgelegd werd. Dan zou je dus in dat script op kunnen nemen dat dat niet meer mag zodra er een vlag aanstaat. Ik zal eens gaan testen met die RecModCount, eens kijken waar die allemaal van toeneemt. Ik denk dat dit echt wel een bewandelbaar pad is hoor... ongetwijfeld is dit een pad naar een oplossing. ik vraag me alleen af, of je die waterdicht krijgt. Wat sanne voorstelt is perfect dicht te timmeren, wat ik voorstel volgens mij ook. ik ben benieuwd wat jouw testen oplevert. ik kwam er straks niet zo snel uit. Quote
Dr_Flash Posted April 29, 2004 Posted April 29, 2004 Nou Rony, ik haal wel weer even een bakzeiltje Jouw voorstel is ten eerste verreweg het eenvoudigste, en ten tweede heb ik ontdekt dat als je een record wijzigt, zelfs al heb je de RecordModificationCount op unstored staan, je kan gewoon wijzigen wat je wil. De nieuwe waarde gaat pas in zodra je naar een ANDER record gaat. Ergens wel logisch natuurlijk, een grote wijziging of een kleine wijziging is nog steeds EEN wijziging, maar je wilt dat allang voor die tijd af kunnen stoppen. Die validatie zoals je voorstelt, op ieder veld zetten, ach dat is ook niet zo'n vreselijke ramp denk ik Quote
Rony Rabijns Posted April 29, 2004 Posted April 29, 2004 Recordlocking is mogelijk vanaf versie 5.5. Dat is het absolute minimum om van die functionaliteit gebruik te maken. even veronderstellen dat Jean niet echt duidelijk was over de subversie, en maw wel beschikt over een 5.5. mogelijke nadelen van recordlocking (edit-record-limiter) zoals Sanne voorstelt : - je kan als "gebruiker" ook niet meer de vlag uitschakelen in geval van nood - de foutmelding is niet personaliseerbaar - stel je bent ingelogd als "god". Dan kan je wel alles wijzigen ! En dat is ook niet de bedoeling me dunkt. @ Jean : het lijkt alsof je nog meer stof tot discussie krijgt ipv minder ! Quote
Sanne Posted April 29, 2004 Posted April 29, 2004 - je kan als "gebruiker" ook niet meer de vlag uitschakelen in geval van nood Onterecht: via scripting en het goede gebruik van globalen kun je wel degelijk de vlag in geval van nood uitschakelen. OOK als gewone gebruiker. Kwestie van slim programmeren - de foutmelding is niet personaliseerbaar Klopt. Je krijgt de algemene melding dat mogelijkerwijs je wachwoord niet toestaat dat je wijzigingen uitvoert. Uh ... dat lijkt me toch wel juist? - stel je bent ingelogd als "god". Dan kan je wel alles wijzigen ! En dat is ook niet de bedoeling me dunkt. Zoals het wachtwoord zegt: dat is juist wel de bedoeling. Als programmeur moet je natuurlijk onbeperkt toegang tot alle functionaliteit van de toepassing. De clou is alleen als programmeur in te loggen als je aan het programmeren bent. En als je gewoon de toepassing gebruikt, als gewone gebruiker. (in werkelijkheid heb ik vaak ook nog een super-gebruiker, naast de programmeur en de gewone gebruiker). het lijkt alsof je nog meer stof tot discussie krijgt ipv minder ! Ah! Toegangprivileges. Ik kan er uren over doorgaan! Quote
Sanne Posted April 29, 2004 Posted April 29, 2004 Die validatie zoals je voorstelt, op ieder veld zetten, ach dat is ook niet zo'n vreselijke ramp denk ik Dat is hopelijk een grapje Quote
Dr_Flash Posted April 29, 2004 Posted April 29, 2004 Die validatie zoals je voorstelt, op ieder veld zetten, ach dat is ook niet zo'n vreselijke ramp denk ik Dat is hopelijk een grapje Heeft Jean 3 miljard velden of zo dan?? Quote
JeanWM Posted April 29, 2004 Author Posted April 29, 2004 Aan allen die zijn en hierna wezen zullen, mijn dank voor de reacties tot dusver.... Ik moet dit effe in een ander programma schrijven, want de connectie is ook niet wat het moet zijn....maar da’s een ander verhaal.... 1. We zitten hier inderdaad met FM 5 (vijf) V3. en enkele printers uit een ver verleden.... 2. We kunnen ons nog niet veroorloven nieuwe versie aan te kopen...onderwijs krijgt hier géén subsidie.... 3. De leerlingen werken liever met deze versie...er zijn meer omwegen mogelijk/noodzakelijk om iets voor mekaar te krijgen, ze zoeken liever zelf naar workarounds om iets te laten werken..ergens kan ik die visie wel bijtreden...het maakt het werk spannender en door de discussies (uitwisselen van ideeen) vraag ik mij soms af wie hier het meeste leert..en ondertussen kunnen we wat sparen voor de aankoop van nieuwe versies..... 4. De ‘controle’ die gedaan wordt na het printen is meer : heeft die aftandse printer alles mooi afgeprint of heeft ie er weer een papierjam van gemaakt en moet alles opnieuw gedaan worden ? De printscript werd dus opgedeeld : is’t goe, dan gaan we verder, is ’t niegoe, dan moet alles oepternief – en dat met een ‘ja’-‘neen’ knoppeke.... 5. Daarna proberen we een methode te vinden om de afgeprinte records te locken (yep, in FM5) @Rony : tot die bevinding waren we hier ook al gekomen, nu nog zoeken om het nadeel te omzeilen.... het lijkt alsof je nog meer stof tot discussie krijgt ipv minder ! ¡¡I loooove that !! @ Dr_Flash : ze willen inderdaad de locking via een script laten gaan, effe een loopje loslaten o.i.d. @Sanne : wachtwoorden blijkt het enige te zijn...maar ik ben niet zo straf in de details van toegangsprivileges (alhoewel ik er veel mee te maken had in een vroeger nucleair leven) Hoe krijg je het voor elkaar dat de records wél kunnen/mogen aangepast worden vóór, zoals ik mijn geval, het afprinten, en niet erna ?¿¿ en hoe brei je dat aan het printscriptje ? En dat alles met pas/wachtwoorden en andere privies ? Quote
Sanne Posted April 29, 2004 Posted April 29, 2004 ------------------ Om nog even de gedachte in een eerdere post af te maken: - je kan als "gebruiker" ook niet meer de vlag uitschakelen in geval van nood Onterecht: via scripting en het goede gebruik van globalen kun je wel degelijk de vlag in geval van nood uitschakelen. OOK als gewone gebruiker. Kwestie van slim programmeren Wat je je namelijk moet realiseren, is dat een global ALTIJD te veranderen is: ook als je record gelocked staat. (Ja, dit kan als een verassing komen!) Stel, je bent met het gebruikerswachtwoord binnen. Het record is gelocked omdat de vlag om staat. Je kunt dus niets meer veranderen. Maar, in de edit-calculatie van het wachtwoord heb je opgenomen dat je WEL mag editten als de global "Edit_g" AAN staat. De calculatie die het wachtwoord toestaat records te editten is dan iets als: -------- IsEmpty(Vlaggetje) or Edit_g -------- In een script zorg je dan eerst dat de Edit_global gevuld wordt. Dat betekent dat daarna het record weer unlocked is, en de gebruiker voor zolang als de global AAN staat, toch kan wijzigen. Goed waterdicht scripten is hierbij wel belangrijk. ------------ OK, ik heb inmiddels Jean's post gelezen, en begrepen dat recordlocking met 5.5 geen optie is. Quote
Rony Rabijns Posted April 29, 2004 Posted April 29, 2004 Wat je je namelijk moet realiseren, is dat een global ALTIJD te veranderen is: ook als je record gelocked staat.(Ja, dit kan als een verassing komen!) Stel, je bent met het gebruikerswachtwoord binnen. Het record is gelocked omdat de vlag om staat. Je kunt dus niets meer veranderen. Maar, in de edit-calculatie van het wachtwoord heb je opgenomen dat je WEL mag editten als de global "Edit_g" AAN staat. De calculatie die het wachtwoord toestaat records te editten is dan iets als: -------- IsEmpty(Vlaggetje) or Edit_g -------- In een script zorg je dan eerst dat de Edit_global gevuld wordt. Dat betekent dat daarna het record weer unlocked is, en de gebruiker voor zolang als de global AAN staat, toch kan wijzigen. Goed waterdicht scripten is hierbij wel belangrijk. helemaal terecht, Sanne, en duidelijk omschreven. maar ik heb intussen begrepen van Jean dat het dus gaat om FM 5v3. en dan wordt het plots weer een ander verhaal ... (ik heb hier geen 5v3 bij de hand, en kan bijgevolg niet checken - tsja, je kan niet alles onthouden - hoe het zit met die record-locking, kan het wel of kan het niet) Quote
JeanWM Posted April 29, 2004 Author Posted April 29, 2004 (ik heb hier geen 5v3 bij de hand, en kan bijgevolg niet checken - tsja, je kan niet alles onthouden - hoe het zit met die record-locking, kan het wel of kan het niet) ....en astkan...hoe Quote
Sanne Posted April 30, 2004 Posted April 30, 2004 Hee! Ik krijg woorden in mijn mond gelegd die ik niet heb gezegd! Ik weet het namelijk wèl heel zeker: recordlocking is mogelijk vanaf versie 5.5. En inmiddels is vastgesteld dat er hier geen sprake is van 5.5 maar van versie 5.0. Onder 5.0 ken ik maar 1 methode om recordlocking te bereiken: - 2 layouts waarvan 1 wel mogelijk is te bewerken en de ander op read-only staat (via groepen + wachtwoorden en het overzicht toegangprivileges), en het volledig dichttimmeren van de navigatie. Het dichttimmeren (met scripts) is nodig zodat op elk moment dat er naar een ander record wordt gegaan, op basis van de voorwaarde, besloten kan worden naar welk layout men gaat. -------------- Waarom staat de andere methode van het valideren van alle velden me zo tegen? Wel nu, bij het valideren wordt pas NA invoer of wijzigen van gegevens geëvalueerd of dit had mogen gebeuren. Stel je voor: het record is afgedrukt, de afdruk is geslaagd en het vlaggetje is omgezet. Het mag nu niet meer mogelijk zijn om welk gegeven dan ook te wijzigen. Een tijdje later kom je weer op het record en je kijkt met je neus en je begint in een veld vanalles te veranderen: dat lukt je! Je kunt in een veld de gegevens wijzigen! Het is pas NA afloop, als je uit het veld probeert te komen, dat de validatie gaat werken en je pas NA afloop van het veranderen vertelt dat je dat niet had mogen doen en dat dus alles wat je het verandert nu weer ongedaan wordt gemaakt. ---------- Wat dacht je van een manier van werken met 2 databases: de ene database voor de records die nog in bewerking zijn, en de andere database (waar bewerken niet is toegestaan) waar je de records die goed zijn afgedrukt naar toe beweegt? Als een soort van archief? Ik vind het zelf geen geweldige methode maar hee, we zijn nog bezig om alle opties te exploreren, toch? ---------- Quote
Sanne Posted April 30, 2004 Posted April 30, 2004 dan moet alles oepternief Uh ... wat is eigenlijk "oepternief"? Quote
Dr_Flash Posted April 30, 2004 Posted April 30, 2004 dan moet alles oepternief Uh ... wat is eigenlijk "oepternief"? "Opnieuw" gok ik Quote
AvD Posted April 30, 2004 Posted April 30, 2004 dan moet alles oepternief Uh ... wat is eigenlijk "oepternief"? "Opnieuw" gok ik Dit betekent gewoon "oepsevès" (op zijn vers, opnieuw)... Quote
JeanWM Posted April 30, 2004 Author Posted April 30, 2004 Wat dacht je van een manier van werken met 2 databases: de ene database voor de records die nog in bewerking zijn, en de andere database (waar bewerken niet is toegestaan) waar je de records die goed zijn afgedrukt naar toe beweegt? Als een soort van archief? Ik vind het zelf geen geweldige methode maar hee, we zijn nog bezig om alle opties te exploreren, toch? ---------- Dat kan een oplossing zijn....uiteindelijk dienen de records na 1 jaar te verhuizen naar een 'archief-bestand'. (bijkomende 'eis'), dus waarom niet onmiddellijk een 'consultatiebestand' maken.... Quote
JeanWM Posted May 1, 2004 Author Posted May 1, 2004 Maar dan vallen we op het probleem van de relaties... Alle records dienen in een 'jaar'-bestand gearchiveerd te worden : blabla2003.fp5, blabla2004.fp5 enz... Dat wprdt weer wat over en 'tweer gepraat om dat het beste voor mekaar te krijgen...of bestaan er 'standaard procedures' voor zoiets... Of moeten we in alle files de relaties aanpassen...hmm, dat zal het wel worden denk ik... Want de developer versie hebben we, wat dacht je, ook niet..... Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.