Replace field contents versus Loopen door records

[Bruno]

Wat gaat het snelst ?

A) Replace the field contents script stap of

B) Loopen door Records en set field gebruiken

 

Ik neem aan A.

 

Wat zijn de voor-en nadelen van het gebruik van A en B ?

[Rony Rabijns]

Wat zijn de voor-en nadelen van het gebruik van A en B ?

 

Met een scriptstap kan je nog wat controle inbouwen onderweg.

Met Replace ga je sowieso 'all the way to the end'.

[rgaros]

Wat gaat het snelst ?

A) Replace the field contents script stap of

B) Loopen door Records en set field gebruiken

 

Ik neem aan A.

 

Wat zijn de voor-en nadelen van het gebruik van A en B ?

 

Mijn ervaring is dat Replace het snelst werkt, maar het loopen:

- sneller gaat zodra je meerdere replace achter elkaar wilt laten uitvoere

- je kan controleren of een record vergrendeld is en daarop actie ondernemen. Replace slaat deze gewoon over (>FM7 ander gedrag?)

- je kan nog andere dingen laten doen en wellicht iets flexibeler zijn met If() situaties.

 

Groet,

Rene

[WJ]

Als het een eenmalige data aanpassingen betreft kan je grote set data veranderen met het importeren van gegevens dit is vele male sneller.

Ik moest eens een aantal codes veranderen in 8000 records met een loop en een set field duurde dat erg lang/ een replace was nog langzamer. Een import was veel sneller.

[Bruno]

Wat ik eigenlijk wil doen is het aantal stuks in een inventaris aanpassen na iedere verkoop.

Het probleem is natuurlijk dat als er een record gelocked is, de boel fout gaat. Dat kan je misschien beter opvangen met een loop.

 

Wat ik nu doe is een unstored rekenveld voor huidige stock (stock-sum(alle verkopen)=huidige stock) in de tabel stock zetten en een 2e veld in de stock creeren (vb. huidige stock_layout) die via een set field geupdate wordt (set field huidige stock_layout;huidige stock).

Op dit moment heb ik een knop "Update stock" in het scherm van de stock waarmee de stock kan geupdate worden (althans het opgevraagde artikel). 'S avonds wordt de volledige stock geupdate met een loop.

 

Ik zou nu een mogelijkheid willen vinden om op een goeie manier de stock na iedere beweging te updaten en niet enkel 's avonds.

Het probleem bij ons is dat er niet enkel aankopen en verkopen naar de stock gaan maar ook bepaalde bewerkingen met de artikels gebeuren (bvb. 2 of meer artikels bij mekaar gooien en de gemiddelde prijs maken)

En vermits er niet altijd zorgvuldig geboekt wordt, moeten er dagelijk ook heel wat correcties op al die bewerkingen gebeuren.

 

Een goeie methode om dit alles up-to-date te houden zou zeer welkom zijn.

[SuperWimmie]

....Ik zou nu een mogelijkheid willen vinden om op een goeie manier de stock na iedere beweging te updaten en niet enkel 's avonds.....

 

Een aantal kanttekeningen, voor zover ik het overzie:

 

a. Een loop kan goed werken, denk er aan dat hij het snelst performt als het scherm niet constant bijgewerkt wordt. Dat scheelt al snel factor 2.

 

b. Als ik het goed heb, zit de kern van jouw probleem in het vinden van de juiste recordset die geupdated moet worden. Ik ken verder jouw oplossing niet, maar alle stock regels elke dag updaten, lijkt mij te veel van het goede. Denk om de wachttijden waarmee gebruikers geconfronteerd kunnen worden. Miscchien kan je een mutatietijd bewaken, zodat je kan vergelijken welke regels aangepast zijn sinds de vorige verwerkingsronde...

 

c. Is het een optie om een aparte computer elke 5 minuten de routine te laten draaien? Scripts zijn in een loop te zetten met een wachttijd.

[Bruno]

Superwimie,

 

bedankt voor je reactie.

Mijn probleem is meer om een methode te vinden waarbij je de stock kan aanpassen d.m.v. een script en niet meer door een unstored calculation.

 

Via scripting heb je altijd kans op gelockte records. Hoe kan je dat opvangen? Je kan natuurlijk via de error-codes de gelockte record vinden . Maar stel dat er van een verkoop van 20 artikels 1 record gelockt is. 19 van de 20 zullen correct behandeld worden, het 1 record wordt niet aangepast. Wanneer ga je dat aanpassen? Het wordt allemaal wat onoverzichtelijk als je delen van een verkoop goed kan wegschrijven en andere niet.

 

Ik heb een artikel en een demo in advisor gelezen over database transactions maar dat is redelijk ingewikkeld.

Zeker als je regelmatig dingen moet verwijderen, aanpassen, opnieuw ingeven,...

[SuperWimmie]

Ik probeer een richting te geven in iets waarvan ik de details niet ken, maar in mijn puntje B. zit een oplossing die het niet uit maakt dat records (tijdelijk) door andere gebruikers gelocked zijn.

Een record dat gelocked is, komt gewoon een ronde later aan de beurt, hetgeen logisch is omdat de gebruiker bezig is met een verandering die op dat moment nog niet definitief is.

 

Stel je voor dat je 2 datumvelden en 2 tijdvelden heb.

Eén datumveld en tijdveld reserveer je voor de mutatiedatum en tijd. Dat moet vanzelf aangepast worden zodra een gebruiker zijn wijzigingen opslaat (kijk hiervoor in de veld-eigenschappen).

 

Het tweede datum en tijdveld kan je laten vullen door jouw script, zodra de wijziging wordt doorgevoerd.

Door de twee datumvelden en de twee tijdsvelden te vergelijken met elkaar, weet je precies welke records er zijn aangepast NA de vorige scriptverwerking.

Mocht een record gelocked zijn, komt hij gewoon 5 minuten later aan de beurt.

 

In deze richting zou je een oplossing kunnen bedenken. Een aandachtspuntje is wanneer records verwijdert worden. Dan is het altijd even goed opletten of alles nog goed gaat.

[WJ]

Om hoeveel gebruikers gaat het. Als de mogelijkheid dat een recordlock zich voordoet klein is zou ik niet een hele transactie tabel gaan aanleggen.

 

Wat ik dan doe is checken of het artikel gelocked is zo ja in een loop met een pauze totdat hij vrij komt. De kans dat een record lock zich voordoet is klein en mocht er een lock voorkomen dan moet de gebruiker even wachten todat het record vrijkomt. Dit doe ik alleen als de kans erg klein is op recordlocks. Je moet natuurlijk de gebruiker wel even informeren.

[Bruno]

De kans is inderdaad klein. Misschien is dat dan wel een oplossing.

Ik twijfel of ik eigenlijk mijn huidige techniek moet aanpassen.

 

Wat ik nu doe is een veld huidige stock als unstored calculation (stock - verkopen) in de tabel stock zetten en een 2e veld ,een gewoon nummeriek veld, om op de layout te zetten. Bij ieder verkoop doe ik

set field (huidige stock_layout;huidige stock) in een loop.

Op deze manier heb ik

1- altijd een juiste stock in de unstored calculation zonder ingewikkelde scripts

2- vermits het kans op locken klein is, een 99% juiste stock op de layout.

Om die ene procent te ondervangen heb ik een knop op de layout ,genaamd "Update stock" ,waarop de gebruiker op ieder moment kan klikken. Die knop doet dan ook een set field (huidge stock_layout;huidige stock). Die zou dan die foute 1% percent moeten opvangen. Bovendien kan de gebruiker geindexeerd opzoeken vermits huige sock_layout een gewoon numeriek veld is.

 

Momenteel heb ik ±30.000 stockitems en 120.000 verkooplijnen.

Sommige artikels beginnen nu iets trager te werken en daarom denk ik nu aan die scriptmethode. Ik neem aan dat het rekenveld de vertraging wat in de hand werkt.

Of misschien gewoon iets regelmatiger archieveren