FMP13 crasht

[hans erik]

Oeps. Is dit normaal:

- ik heb een portal die gekoppeld is met een global field. Dus ik vul in de global een letter in en dan toont de portal alle records waarvan de naam met die letter begint. Niet gefilterd, maar via de self-relatie personen::g_beginletter = personen::indexveld. In het indexveld zitten dus de beginletters. Werkt uitstekend.

- Een klik op een portaalregel voert mij via een Go To Related Record naar de persoon.

 

Nu heb ik bijvoorbeeld alle personen in de portal waarvan de achternaam met A begint, en in g_beginletters staat dus de letter A.

 

Haal ik nu de A uit g_beginletters weg of veranderd ik de waarde en klik ik op een portaalregel zonder een commit te geven (de inhoud van de portal laat nog de oude recordset zien), dan crasht FileMaker Pro:

 

 

Process:         FileMaker Pro [18576]
Path:            /Applications/FileMaker Pro 13 Advanced/FileMaker Pro Advanced.app/Contents/MacOS/FileMaker Pro
Identifier:      com.filemaker.client.advanced12
Version:         13.0.4 (13.0.4)
Code Type:       X86 (Native)
Parent Process:  launchd [280]
User ID:         504

Date/Time:       2015-02-13 22:40:42.811 +0100
OS Version:      Mac OS X 10.8.5 (12F45)
Report Version:  10

Interval Since Last Report:          200663 sec
Crashes Since Last Report:           3
Per-App Interval Since Last Report:  168211 sec
Per-App Crashes Since Last Report:   3
Anonymous UUID:                      976C66DD-DCF0-6E26-E375-BA5C06A1BB5C

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000064

...enzovoorts 

 

 

Bug of feature?

[menno]

Er is iets vreemds aan de hand met die globals en commit-en in FM. Als je een global gebruikt als basis van een relatie, dan is het voldoende om de global in te stellen en het veld te verlaten (zonder het record vast te leggen) en dan werkt die relatie in die zin dat een portal op basis van die relatie meteen records gaat tonen. Wil je echter op basis van die global iets berekenen (in een veld), dan moet je het record wél vastleggen, anders werkt de berekening gewoon niet. Het lijkt er hier op dat GTRR ook moet worden beschouwd als een berekening, maar dat FM er op crasht, dat vind ik toch wel een bug.

 

Ik gebruik zelf globals wel eens om vastgelegde records (als in: die mogen niet meer worden gewijzigd) te "ontgrendelen", door met de "eigen privileges" van de records te kijken naar een global waar een 1 in moet staan, wanneer een record tóch moet kunnen worden gewijzigd en dat werkt alleen maar na een commit.

[hans erik]

Menno, ik weet niet of een GTRR een 'berekening' is, zeker is in elk geval dat de GTRR (via een script of direct 'onder de knop' ) natuurlijk een pointer naar het record ophaalt uit de cache. Een exit field uit de global zorgt ervoor dat de cache geupdate wordt, maar in dit geval is dat niet gebeurd, want technisch staat de cursor nog in het global field.

Je zou dus verwachten dat de GTRR de oude pointer pakt en dat je dus naar het verkeerde record springt. Maar kennelijk doet die GTRR eerst iets anders en daardoor raakt FileMaker de kluts kwijt.

 

Heb inmiddels wat getest en:

- het treedt ook op met FMPA13v5, en ook onder OSX 10.9 en Windows 7 (heb Yosemite niet getest, maar het heeft natuurlijk niets met het OS te maken).

- FMP12 gedraagt zich normaal, in die zin dat de portal leeg wordt en er niks gebeurt.

 

Dat FileMaker iets raars doet vind ik acceptabel, maar dat alles in 1 klap crasht is natuurlijk te gek voor woorden. Toch geen klein foutje!

 

Ik heb overigens ook een workaround gevonden: als je het globale veld voorziet van een script trigger 'on validate' en het scriptje doet een Commit, dan gaat het wel 'goed' zo te zien.

 

Misschien ook iets voor onze zuiderburen?

 

HE

[hans erik]

Ik heb het ook geprobeerd met een tweede veld: een berekend veld dat de waarde van de global overneemt en als Foreign Key voor de relatie fungeert.

Maar ook daar geldt natuurlijk: zolang de cursor nog in het globale veld staat, wordt de relatie niet geëvalueerd en crasht de boel.

[menno]

De crash met GTRR beschouw ik als een symptoom, want ik bedoel eigenlijk dat er iets raars is met het evalueren van de waarden in globals door FM.

 

In het ene geval werkt het aanpassen van de global-waarde zonder commit meteen door als in het tonen van records in een portal. In datzelfde geval werkt een knop in die gerelateerde records waarmee je GTRR uitvoert niet (en crasht FM zelfs!), terwijl dat wel zou werken als je een commit zou doen vóór de GTRR.

Exact hetzelfde lijkt het probleem als ik een global gebruik om een record te "ontgrendelen", dat werkt ook pas nádat er een commit is uitgevoerd (overigens is dit niet alleen in FM13 een probleem, dat was voorheen ook al zo in FM12 en FM11).

[hans erik]

Volgens mij werkt het anders.

 

- als je een portal ververst door een global veld te wijzigen (zoals ik doe in het voorbeeld), wordt er in principe niks gecommit. Een global wordt niet gecommit, als je dus op TAB drukt en je verlaat het globale veld, wordt alleen de portal vernieuwd.

 

- in jouw geval (een berekening om de record-privileges te evalueren) wordt er impliciet misschien wel een commit uitgevoerd omdat FileMaker die berekening moet uitvoeren. En FileMaker moet een tripje naar het record maken om zo te zeggen, ook om de privilegeset te raadplegen.

 

Ik zou hier op de volgende FMSummit wel eens een lezing over willen horen, want het is me ook niet duidelijk waar dit hele circus zich afspeelt. Als je een evaluatie doet van zo'n privilege op record-niveau, gebeurt dat dan op de server? Of op de client? Of beide?

 

HE

[SuperWimmie]

Logisch dat Filemaker een globaal moet committen voor een berekening.

Berekeningen zijn data gerelateerd, je wijzigt uitkomsten in andere velden die andere gebruikers ook toepassen

 

Logisch dat Filemaker relaties legt met andere tabellen, zodra het globale veld is aangepast.

Je wijzigt per slot van rekening geen data en je zit geen enkele andere gebruiker in de weg...

 

Het werkt verwarrend als je het globale veld centraal zet en niet de gedachte er achter.

Logisch dat je het onlogisch vind

[hans erik]

Logisch dat Filemaker een globaal moet committen voor een berekening.

Berekeningen zijn data gerelateerd, je wijzigt uitkomsten in andere velden die andere gebruikers ook toepassen

 

Nee, een commit heeft te maken met een disk-operatie en alle berekeningen met een globaalveld zijn 'niet-opgeslagen'. Maar als je voor een niet-opgeslagen berekening een opgeslagen waarde moet ophalen, kan dat wel een commit veroorzaken denk ik. Maar ik zou van FileMaker wel eens wat meer informatie op dit punt willen. Zoals Menno ook zegt, een Global Field is een raar beestje.