G.B.BREUKEL Geplaatst: 19 januari 2009 Delen Geplaatst: 19 januari 2009 Heeft iemand een oplossing voor het volgende. Ik een tabel werkbonnen, nu doe ik het volgende, 1: ik kies een klant en ik ga naar het lay-out werkbon. 2: in de werk bon zet ik nog wat gegevens en dan wil ik afsluiten. 3: ik het ingesteld dat er eerst gevraagd moet worden of het record opgeslagen moet worden, ik krijg de keuze bewaar, annuleer, bewaar niet. Nu komt het, ik zeg bewaar niet maar omdat ik een werkbonnummer automatische laat maken blijft hij optellen elke keer als ik bewaar niet aan klik. Is hier een oplossing voor dat hij het record dat hij aangemaakt heeft annuleert en het nummer terug zet waar ik geëindigd ben. Ik begin bv bij werkbon 100 en als ik dan een bon maakt dan is het 101 maar als ik zeg niet bewaren moet het weer 100 worden en niet 102 Ik hoor graag Gerard Quote Link naar reactie
0 Pescador Geplaatst: 19 januari 2009 Delen Geplaatst: 19 januari 2009 Bij veel van de bestanden waar ik mee werk heb ik de stap "Verwijderen" als script opgeslagen. Als onderdeel van het verwijderen heb ik de scriptstap "Volgende volgwaarde instellen" toegevoegd, waarmee je het automatische recordnummer weer kunt bijwerken. Quote Link naar reactie
0 JeanWM Geplaatst: 20 januari 2009 Delen Geplaatst: 20 januari 2009 Je zou het sandbox principe kunnen toepassen bij het aanmaken van bons. Dan wordt het serialnummer pas aangemaakt als je de sandbox verlaat. De manier waarop je de sandbox verlaat (bevestiging of niet), zal bepalen of je serial aangepast wordt. Je werkt dus met een derivaat van het behangpapier principe. Geen recordverwijdering met aanpassen van serials. Geen overkill scripts. Quote Link naar reactie
0 edc Geplaatst: 20 januari 2009 Delen Geplaatst: 20 januari 2009 Je zou het sandbox principe kunnen toepassen bij het aanmaken van bons.Dan wordt het serialnummer pas aangemaakt als je de sandbox verlaat. De manier waarop je de sandbox verlaat (bevestiging of niet), zal bepalen of je serial aangepast wordt. Je werkt dus met een derivaat van het behangpapier principe. Geen recordverwijdering met aanpassen van serials. Geen overkill scripts. Jean, zou het mogelijk zijn om voor de simpele duiven onder ons deze 2 princiepes wat nader toe te lichten? Quote Link naar reactie
0 JeanWM Geplaatst: 20 januari 2009 Delen Geplaatst: 20 januari 2009 In 't kort dan maar... Voor het behangpapier doe je best een search op het forum… Sandbox principe is vrij eenvoudig. Je zet een kind in een zandbak om het te laten spelen in een ‘gecontroleerde omgeving’. Je geeft het alle nodige zaken (toys) om rustig een mogelijke creatie te maken, emmertjes, shopjes, vormen, gritsel…. Je kunt zelfs meerdere kindjes in de zandbak zetten. Zolang ze daarin blijven plegen ze ergens anders geen havoc. Pas als ze gedaan hebben met spelen, of als hun ‘creatie’ af is, ‘zet je ze weer in huis’. Zo ook met data/record aanmaak. We verplaatsen de aanmaak naar een table buiten de eigenlijke applicatie (sandbox). Die table heeft wel alle nodige verbindingen (lookups/relaties etc) om de aanmaak tot op een zeker niveau te kunnen doen (toys) Maw. De aanmaak van een nieuw record heeft nog geen invloed op bv serials. Pas als je zeker bent van alles, juistheid gegevens etc. is er een scriptje dat de gegevens overzet naar de eigenlijke toepassing en de velden in de (aanmaak)table worden weer leeggemaakt. Of dat record wordt verwijderd. Het is pas bij het overzetten (van juiste/gewenste) gegevens dat applicatie beïnvloedende zaken worden gedaan, zoals aanmaak serial, ID, summary berekeningen enz. In pre 7 zouden we er globals voor gebruikt hebben, maar nu is het met lokale variabelen in een SetField() script zoals spelen in een, jawel….sandbox. Je kunt zelfs de aangemaakte sandbox records voor dagen laten zitten, kan geen kwaad indien je bv voorlopig nog niet alle gegevens hebt. Pas bij het 'registreren', of welke naam je er ook aan geeft, worden de gegevens permanent opgenomen. En dat allemaal maakt deel uit van de business rules.... (daar gaan we weer ) Quote Link naar reactie
0 Ron9_15 Geplaatst: 20 januari 2009 Delen Geplaatst: 20 januari 2009 Je laat de gebruiker al bevestigen via een script, enigste wat je nodig hebt is een extra tabel ; laten we ze serial noemen.Indien de gebruiker bevestigd maak je in die serial tabel ( 1 veldje 'volgnr' auto serial) een nieuw record aan, sla het volgnr op in een var en wis vervolgens het record.Deze methode werkt multi user ! Quote Link naar reactie
0 JeanWM Geplaatst: 25 januari 2009 Delen Geplaatst: 25 januari 2009 ...en wis vervolgens het record.Deze methode werkt multi user ! Waarom aanmaken en dan wissen? Je gaat daarmee lijnrecht in tegen de extended normalisatieregels. Quote Link naar reactie
0 Ron9_15 Geplaatst: 25 januari 2009 Delen Geplaatst: 25 januari 2009 Sja Jean, ik trotseer nogal graag een storm maar heb ook geen zin om een miljoen records met enkel een volgnr te bewaren.Indien je een betere kent be my guest. Quote Link naar reactie
0 JeanWM Geplaatst: 25 januari 2009 Delen Geplaatst: 25 januari 2009 .... maar heb ook geen zin om een miljoen records met enkel een volgnr te bewaren.Indien je een betere kent be my guest. De serials zitten al als gegeven in een table. Er is geen reden om nog eens een table aan te maken enkel om serials op te bouwen die al bestaan. Dat is redundant. Je verwart attribute met entity en maakt het daardoor nodeloos ingewikkeld. Je maakt een vorm van index, terwijl die index al bestaat. Je doet dus aan table fragmentation, terwijl dat niet nodig is. Quote Link naar reactie
0 Ron9_15 Geplaatst: 25 januari 2009 Delen Geplaatst: 25 januari 2009 Is een mooi woord redundancy maar ben het niet eens met je, m.i. is er geen verwarring.Ik zal je een voorbeeld geven, voor een fashion label moeten er EDI berichten verzonden worden MET een volgnr naargelang de expediteur.Mijn volgnr bestaat dus niet in de table (of ik moet er 3 , 4 enz... voorzien ).Daarom heb ik extra volgnr tabellen gebruikt,waarin ik wis louter om geen storage te verspillen en bovendien record locking (als je globals zou gebruiken bvb) vermijd.In dit geval is het zoveel handiger om mijn attribute als entity te beschouwen, na vastleggen expediteur en verzending maak ik immers pas het vereiste volgnummer aan zodat er een correcte EDI de deur uit kan.Ik vind het een handig systeem en zie niet in waarom ik nauwgezet de regeltjes moet volgen ??? Een sandbox opbouwen is stukken complexer en je moet met zoveel meer rekening houden op gebied van vereistheid ,validatie en security.Ik zou deze oplossing enkel aanraden als je echt moet, zeker voor beginnende developers. Quote Link naar reactie
0 JeanWM Geplaatst: 25 januari 2009 Delen Geplaatst: 25 januari 2009 In dit geval is het zoveel handiger om mijn attribute als entity te beschouwen,... Kan zijn voor jou, maar de OP had het over werkbonnummers, en die zijn een attribute van de entity werkbon. En je geeft zelf toe dat je volgnummer een attribute is.... Je houdt geen rekening met de fundamentele vereisten van een entity: - Significant - Generic - Fundamental Je doet hier aan domainverwarring. Een sandbox opbouwen is stukken complexer en je moet met zoveel meer rekening houden op gebied van vereistheid ,validatie en security,... Helemaal niet, het is een derivaat van de eigen FileMaker structuur, waar je ook een Commit record moet doen. Je vertraagt alleen het eigenlijke invoerproces. Quote Link naar reactie
0 Ron9_15 Geplaatst: 25 januari 2009 Delen Geplaatst: 25 januari 2009 Je houdt geen rekening met de fundamentele vereisten van een entity:- Significant - Generic - Fundamental Ik ga wel akkoord met je theorie maar vermoed dat je niet veel realtime RAD doet , mijn oplossing zal naar wens functioneren en is in minder dan 10 minuten ingebouwd.We baseren ons bovendien beiden op een externe tabel dus waarom die rompslomp met een sandbox, wat doe je als er in de werkbonnen bvb 15 velden zitten die allen eigen validaties, aec zijn enz... ook alles in je sandbox opbouwen.Theoretisch allemaal mooi, in de praktijk soms een hoop overbodig en duur werk (behalve als men in de kruising gratis werkt natuurlijk), ben wel benieuwd naar de mening van andere developers omtrent de 2 methodes. ( Poll misschien ) Tot slot wil ik afsluiten met de oppering dat het niet altijd volgens de boekjes moet om tot een gewenst resultaat te komen... dan zou onze job toch wel saai worden niet. Quote Link naar reactie
0 JeanWM Geplaatst: 25 januari 2009 Delen Geplaatst: 25 januari 2009 ...maar vermoed dat je niet veel realtime RAD doet .... Puur jumping to assumptions. Wij verdienen onze lokale boterham, en iets om er tussen te leggen, met het voortdurend herwerken van database applicaties die door anderen verkeerd zijn opgebouwd en op lange of korte termijn vastlopen, of volledig onoverzichtelijk zijn zodat mogelijke aanpassingen resulteren in het 'opnieuw moeten beginnen'. Maar ik klaag niet. Doe rustig verder. Klanten (zelfs, en meestal, van andere 'developers') komen vroeg of laat toch..... Daarom dat we na 25+ jaar aan 'herstel-development' te hebben gedaan, we nu werken aan gedegen opleiding van database developers. En met succes. Tot slot wil ik afsluiten met de oppering dat het niet altijd volgens de boekjes moet om tot een gewenst resultaat te komen..... Je vergat wel iets: ... om tot een gewenst niet blijvend resultaat te komen... ...wat doe je als er in de werkbonnen bvb 15 velden zitten die allen eigen validaties, aec zijn enz.... Iets wat bijna niemand doet, de applicatie uittekenen en documenteren voor we beginnen rond te klikken....en dan voortdurend documenteren.... Quote Link naar reactie
0 Ron9_15 Geplaatst: 25 januari 2009 Delen Geplaatst: 25 januari 2009 Pffff oei oei blijkbaar enkele dingen in het verkeerde keelgat Maar ik klaag niet. Doe rustig verder. Klanten (zelfs, en meestal, van andere 'developers') komen vroeg of laat toch Inderdaad, heb er verschillende ... Je vergat wel iets: ... om tot een gewenst niet blijvend resultaat te komen... Belachelijk, misschien moeilijk toe te geven dat er eenvoudige solide oplossingen bestaan voor iets waar jij enkele dagen development nodig hebt.Wat zou er wel niet blijvend zijn ? Iets wat bijna niemand doet, de applicatie uittekenen en documenteren voor we beginnen rond te klikken....en dan voortdurend documenteren.... Denk toch dat dit ook door anderen gedaan wordt en teken ook uit, maar de kern vd vraag wordt zo netjes gemeden, lijkt op een antwoord dat je zou verwachten van Belgische politici Je maakt het echt nodeloos complex indien je een sandbox wil opbouwen om enkel en alleen een werkbonnummer toe te voegen.Dat was de initiële vraag en ik laat het aan de vraagsteller over hoe hij dit wil oplossen.De tweede suggestie (replace serial) is onbruikbaar in een multi-user environment.Blijft dus mijn oplossing (maak volgnr aan na goedkeuring order) of jou sandbox routine die eveneens na goedkeuring wordt uitgevoerd over. Sluit met deze af en zie wel hoe anderen reageren ... Quote Link naar reactie
0 JeanWM Geplaatst: 25 januari 2009 Delen Geplaatst: 25 januari 2009 Toch valt het opnieuw op hoe weinigen er echt kunnen lezen. Quote Link naar reactie
Vraag
G.B.BREUKEL
Heeft iemand een oplossing voor het volgende.
Ik een tabel werkbonnen, nu doe ik het volgende,
1: ik kies een klant en ik ga naar het lay-out werkbon.
2: in de werk bon zet ik nog wat gegevens en dan wil ik afsluiten.
3: ik het ingesteld dat er eerst gevraagd moet worden of het record opgeslagen moet worden, ik krijg de keuze bewaar, annuleer, bewaar niet.
Nu komt het, ik zeg bewaar niet maar omdat ik een werkbonnummer automatische laat maken blijft hij optellen elke keer als ik bewaar niet aan klik.
Is hier een oplossing voor dat hij het record dat hij aangemaakt heeft annuleert en het nummer terug zet waar ik geëindigd ben.
Ik begin bv bij werkbon 100 en als ik dan een bon maakt dan is het 101 maar als ik zeg niet bewaren moet het weer 100 worden en niet 102
Ik hoor graag
Gerard
Link naar reactie
14 antwoorden op deze vraag
Aanbevolen berichten
Doe mee aan dit gesprek
Je kunt dit nu plaatsen en later registreren. Indien je reeds een account hebt, log dan nu in om het bericht te plaatsen met je account.