Records worden niet verwijderd?

[hans erik]

Ik kom het volgende probleem tegen: ik laat FMS via Perform Script on Server een groot aantal records verwijderen, waarna ik het restant vanuit de client exporteer naar een CSV bestand.

Het lijkt er echter op dat de records niet allemaal echt weg zijn, althans het duurt even en de FileMaker client heeft dat niet in de gaten en gaat aan het werk met een heleboel (lege!) records die er eigenlijk niet meer zouden moeten zijn!

Het is verklaarbaar in die zin, dat je natuurlijk vanuit de client weer uit een andere context opereert, daarom probeer ik het op te vangen door een commit en een Refresh Window ertussen uit te voeren. Maar dat maakt niks uit. Voeg ik een pauze van 5 seconden in dan gaat het wel goed.

 

Als ik het script uitvoer in de Debugger gaat het ook altijd goed, maar in een gewone run gaat het dus altijd fout zonder die pauze!

 

Maar het probleem is:

a. Refresh Window doet dus niet altijd wat het volgens mij zou moeten doen, namelijk de cache leegmaken en

b. een pauze van 5 seconden leuk, maar wie zegt mij dat dat in de toekomst voldoende is? Als er meer records verwijderd worden? Andere gebruikers actief zijn?

 

 

Is er een methode die betrouwbaarder is dan deze houtje-touwtje oplossing?

 

NB ik krijg ook een raar resultaat:

 

 

HE

[menno]

Heb je bij PSoS wel "Wait for completion" aanstaan? In dat geval zou in één keer het aantal records naar beneden moeten gaan, zodra het script op de server klaar is. Staat WFC uit, dan zie je iedere keer chuncks van records verdwijnen én het duurt langer. Ik heb het bij mij even getest op een DB met 200M records waar ik iedere keer 20K records verwijderde.

 

Dat rare getal van dat er "meer records zijn gevonden dan dat er in de DB aanwezig zijn" ken ik alleen van corrupte DB's, ik zou dus een kloon van die DB maken en daarna de (eventueel herstelde) data weer importeren.

[hans erik]

Ja, wait for completion staat altijd standaard aan bij mij. Ik zie de recordcount overigens in een apart venster wel teruglopen, niet in één klap van x naar y dus. Wel is het zo dat het aantal records dat daarna gekopieerd moet worden keurig op het juiste aantal staat maar kennelijk is er dus voor de client nog een verschil tussen 'what you see' en 'what you get'.

Misschien heeft de client nog tijd nodig om de found set te updaten. De pointers naar de records zijn er (deels) nog, maar bij het opvragen van de data zijn de records natuurlijk leeg.

 

 

Ik zal ook nog eens goed de werking van refresh window in relatie tot de context nalopen, want ik vermoed dat daar de oorzaak ligt ( en de oplossing dus).

De records worden gekopieerd via een relatie en een portal, dus je zou verwachten dat een Refresh Window altijd de interne cache vervangt.

[menno]

HE ik heb hetzelfde nog eens geprobeerd met 10x zoveel records (ca 200K) en dan zie ik min of meer hetzelfde gedrag als jij hebt gezien. Min of meer is op de volgende manier:

 

• als ik dezelfde gevonden set op de client heb als welke die ik op de server met PSoS verwijder, dan wacht FM netjes totdat alle records werkelijk zijn verwijderd
  
• bestaat de gevonden set op de client voor een deel uit de te verwijderen set, dan gebeurt dat ook keurig, maarrrr.....
  
• heb je geen beperkte set, maar sta je in alle records gevonden, dan wordt het verwijderen ineens op de achtergrond uitgevoerd en kan je FM andere dingen laten doen terwijl langzaam het aantal records afneemt door het verwijderen... (duurt een minuut ofzo)
  
• meer records gevonden dan dat er in de tabel zijn opgeslagen, heb ik niet kunnen reproduceren

Ik ga dit nog eens wat uitvoeriger bekijken, daar rustig een demo'tje van in elkaar draaien en dat ga ik eens bij FMI neerleggen. Kijken wat zij er van vinden

[hans erik]

Ik vrees dat de optie 'Wait for completion' teveel verwachtingen wekt.

 

Het serverscript verwijdert natuurlijk alle records, maar ik vraag me af waarom de Refresh window die ik op de client uitvoer dan een incompleet resultaat geeft.

Misschien dat de servercache nog niet bijgewerkt is en de client zijn pointers uit die cache haalt? Dat kan toch niet!

[hans erik]

Ik heb nu veel getest, zowel lokaal als via een WAN verbinding (ik log dan aan via de Wifi verbinding van de buren, zodat je een situatie hebt die vergelijkbaar is met die van echte klanten).

En ik word er niet vrolijk van, krijg toch erg variabele resultaten om het netjes uit te drukken.

 

Eigenlijk moet je alle PSoS in het bestand zelf draaien met uitsluitend lokale koppelingen, en dan nog is de timing (en daarmee de wisselwerking tussen de wat de client ziet en de server beschikbaar heeft) een uiterst onzekere factor.

 

Ik neem die PSoS stappen in een soort processcript op, en draai er dus meerdere achter elkaar. Maar ook al doe je overal Wait for completion en een Refresh en Commit met alles erop en eraan, dan nog kun je er NIET van uitgaan dat de volgende stap de database aantreft zoals je verwacht.

 

Krijg toch de indruk dat het hier betaware betreft!

[menno]

Het lijkt dus erg afhankelijk van wat de fysieke omvang van de data (en de bijbehorende indexen) is die je verwijderd.

 

De enige veiligheid die je kan inbouwen is eerst uitzoeken wat je precies gaat verwijderen, daar het eerste en het laatste record van opslaan (de ID's uiteraard) en na het afvuren van je PSoS-script en voordat je de vervolgacties gaat uitvoeren, letterlijk controleren of de actie is afgemaakt ...... kan je dus net zo goed in zulke gevallen PSoS beter niet gebruiken, want je moet er toch op wachten hé?

 

Zit nu zelf met een soortgelijk probleem bij een klant ... die heeft een FM-systeem in zijn bedrijf staan dat ik heb gebouwd en heeft bij een FM_hosting-provider bestanden op de FM-server in een webomgeving staan waar ik met PSoS ook wat gegevens moet verwerken (bij die omgeving kan ik zelf helemaal niks). Ook daar hebben we synchronisatieproblemen...

[hans erik]

Kom nog een soortgelijk probleem tegen, nu met ExcecuteSQL: ik wil na een batchimport gevolgd door een aantal bewerkingen met PSoS een samenvatting produceren voor de gebruiker: hoeveel geïmporteerd, hoeveel records werden verwijderd, status bijgewerkt, etc.

Kun je natuurlijk mooi ExecuteSQL voor gebruiken, vanuit het user bestand. Maar als je niet eerst een pauze inlast met een commit en een refresh blijven de query results gewoon leeg (oftewel: '?').

 

Vind ik toch niet zo netjes, vooral omdat ExecuteSQL onafhankelijk van de context is mag je eigenlijk verwachten dat de SQL engine altijd wel betrouwbare resultaten geeft. Niet dus. Oppassen geblazen!

[menno]

De conclusies lijken dan toch:

• FMServer heeft tijd nodig om wijzigingen in de dataset te distribueren naar de clients.
• De clients in zulke gevallen soms met een andere dataset te maken kunnen hebben dan dat er daadwerkelijk op de server nog aanwezig is.

Mijn vraag is daarom:

• Hoe beheers je dat?

Want in jouw voorbeeld verstuur vanaf clientX een PSoS opdracht we en ga je vervolgens iets op die clientX doen met logging etc. Je kan blijkbaar wat veiligheid inbouwen de te commit-en en te refresh-en, maar:

• Hoe doe je dat dan op een andere client die niet ''weet'' dat er met PSoS iets wordt bewerkt, of net is bewerkt?
• Hoeveel fouten als deze gaan er in een multi-user-omgeving optreden?
• Hoe vang je die af?
• Zou een transactie-systeem nuttig zijn (zoals bijvoorbeeld in: alleen maar wijzigingen als records op gaan slaan)?
• Zo ja, hoeveel trager gaat dan databewerking/-lezing plaatsvinden?
• Of wordt het probleem dan nog erger?
• Moet je in zulke gevallen misschien een heel ander schema gaan ontwerpen?