Ga naar inhoud

GTRR 101 fout


rgaros

Aanbevolen berichten

Ik zie het probleem al jaren en weet niet of ik het ooit aan FMI heb gemeld, maar wil het eens uitzoeken. Zelf programmeer ik al jaren om dit probleem heen. Moet nog even uitzoeken vanaf welke versie dit bestaat, in ieder geval FM14-16.

 

Probleem:

gebruik in een script Ga naar gerelateerde record[] met de optie 'Alleen gerelateerd records' en 'Overeenkomst met alle record in huidige gevonden reeks'

als het huidige record GEEN gerelateerde records heeft, dan worden de andere gerelateerde records wel gevonden maar volgt onterecht een foutnummer 101.

 

Wie heeft dezelfde ervaring?

 

Mvg,

René

Link naar reactie

Het klopt dat je die foutmelding/code krijgt, maar ik vind hem eigenlijk wél terecht.

 

Die fout krijg je omdat de context voor de fout uitgaat van het actieve record en niet van de gevonden set. GTRR van gevonden set is pas sinds FM8 beschikbaar, maar de originele functie is nog steeds het uitgangspunt van GTRR en in die context is de fout terecht.

 

Ik zou het ivm de backwards compatibiliteit eigenlijk ook raar vinden als je fout 101 in dit specifieke geval niet zou krijgen.

 

Je zou hier, denk ik, 4 situaties willen kunnen herkennen:

* Alle records hebben kind-records: error = 0

* Huidige record heeft geen kinderen: error = 101

* Ander record(s) heeft geen kinderen: error = 121

* Geen enkel record heeft kinderen: error = 122

 

De laatste 2 foutcode bestaan nu helemaal niet FM, maar je ziet meteen waar het probleem ligt. Fout 101 is zoals het nu werkt en die is gemakkelijk te herkennen, maar de andere 3 fouten betreffen alle records van de gevonden set.

 

Bestaat die set uit slechts 10 records, dan zal het een makkie zijn om te calculeren welke fout er eventueel optreedt. Het uitrekenen van error = 0 over een miljoen records zal alleen niet zo snel gaan en zal een flinke impact hebben op de snelheid. Zou ik FMI zijn, dan zou ik het laten zoals het nu is. De ontwikkelaar zoekt zelf maar uit of hij zijn set zelf controleert op het hebben van child-records.

 

Grappig om even over na te denken :D

Link naar reactie

Dag René,

 

Ik dacht dat het zo was: als 1 of meerdere records in de gevonden set geen gerelateerde records heeft, krijg je die foutmelding. Ik kan me vergissen, maar ga het nu even niet uitzoeken, het is zaterdag.

 

Heb het ooit een keer doorgegeven in mijn support tijd. Maar kreeg als antwoord dat dit "not a bug" and "expected behaviour" was.

 

Error handling in FileMaker is dringend aan vernieuwing toe, je hebt gelijk dat je dit aan de kaak stelt.

Wat ik o.a. mis:

 

1. Error levels: zoals hier het geval is, er is inderdaad iets aan de hand, maar het is geen kritische fout, dit heb je ook in exit loop script steps, en dit maak de "pauze on error" feature eigenlijk zo goed als nutteloos. Ik zet tegenwoordig "exit loop if Get ( CurrentRecordNumber ) = Get ( FoundCount )" vlak voor "go to record/request next [exit after last]". Om het server log niet te flooden, want in server side scripts wordt dit anders ook nog eens gelogd.

 

2. Echte error handling. De "Set error capture" script stap uitgebreid, of een nieuwe script stap "Set error handling script". Waar je dus in terecht komt als het fout gaat, met nuttige parameters beschikbaar in dat script. Je hoeft dan niet achter elke script lijn 3 of 4 extra lijnen te schrijven om een mogelijke error conditie op te vangen.

 

3. Meer error codes. Als ik een "import file" script stap gebruik, dan kunnen er "on runtime" meerdere errors voorkomen. De import kan mislukken, ik kan de keuze van de te importeren file annuleren, ik kan het openen van een gerelateerde file annuleren ( gebeurd wanneer de import interactief is ). De laatste 2 errors hebben als waarde "1". Gebruiker annuleerde. Niet genoeg. De ene is kritisch, de andere mogelijk niet.

 

4. Volledige error capturing. Als bijvoorbeeld de connectie met een file verloren gaat, wil ik dat in software opvangen, en geen dialoog krijgen. Belangrijk voor robots en niet attente of "minder technisch aangelegde" gebruikers.

 

5. Error handling voor formules.

Bijvoorbeeld:

Set Field [ Untitled::field ; 1/0 ] 
Show Custom Dialog [ Get ( LastError ) ] 

Zal geen foutcode geven. Omdat de foutcode die van de "Set Field" instructie is. Nochthans doen we hier iets dat eigenlijk zou kunnen opgevangen worden. Get ( LastCalculationError ) ? Ver gezocht? Wat bijvoorbeeld met situaties? situaties waar een plug-in niet geladen is. We hebben op het ogenblik een knullig EvaluationError ( Evaluate ()) om zo'n dingen heel proactief te gaan opvangen. Dat wil ik echt niet overal gaan implementeren.

 

O je denkt dat jij met wat frustraties rondloopt... :mrgreen:

Link naar reactie
Het klopt dat je die foutmelding/code krijgt, maar ik vind hem eigenlijk wél terecht.

 

Die fout krijg je omdat de context voor de fout uitgaat van het actieve record en niet van de gevonden set. GTRR van gevonden set is pas sinds FM8 beschikbaar, maar de originele functie is nog steeds het uitgangspunt van GTRR en in die context is de fout terecht.

 

Ik zou het ivm de backwards compatibiliteit eigenlijk ook raar vinden als je fout 101 in dit specifieke geval niet zou krijgen.

De scriptstap doet keurig wat er gevraagd wordt (ik hoop dat dat duidelijk was), het vindt alle gerelateerde records van de huidige reeks. Dan verwacht je gewoon 0 als LaatsteFout. Dat het huidige record geen gerelateerd record heeft doet dan niet ter zake omdat het niet vereist is/gevraagd wordt.

Backwards compatibility is helemaal niet aan de orde omdat het een nieuwere optie is die je bewust aan zet en je script op aanpast.

 

Je zou hier, denk ik, 4 situaties willen kunnen herkennen:

* Alle records hebben kind-records: error = 0

* Huidige record heeft geen kinderen: error = 101

* Ander record(s) heeft geen kinderen: error = 121

* Geen enkel record heeft kinderen: error = 122

 

De laatste 2 foutcode bestaan nu helemaal niet FM, maar je ziet meteen waar het probleem ligt. Fout 101 is zoals het nu werkt en die is gemakkelijk te herkennen, maar de andere 3 fouten betreffen alle records van de gevonden set.

Als er geen enkel gerelateerd record wordt gevonden gevonden krijg je fout 401.

 

Bestaat die set uit slechts 10 records, dan zal het een makkie zijn om te calculeren welke fout er eventueel optreedt. Het uitrekenen van error = 0 over een miljoen records zal alleen niet zo snel gaan en zal een flinke impact hebben op de snelheid. Zou ik FMI zijn, dan zou ik het laten zoals het nu is. De ontwikkelaar zoekt zelf maar uit of hij zijn set zelf controleert op het hebben van child-records.

Hé!? Vreemde redenering. FM zoekt per record in de index de bijbehorende records en verzamelt die in een lijst van record ID's. Het weet in dat proces meteen of er een record geen gerelateerde records heeft. Zelfs als het een intersectie van twee verzamelingen sleutelvelden maakt, gezien de traagheid bij veel records lijkt het daar niet op, dan maakt het niet uit hoeveel gerelateerde records er precies worden gevonden. Ik denk dat het bepalen of 'Ander record(s) heeft geen kinderen' dan juist meer tijd kost. Al op de Commodore 64 schreef ik dit soort code zelf, komt nogsteeds van pas. :-)

 

Mvg,

René

Link naar reactie
Ik dacht dat het zo was: als 1 of meerdere records in de gevonden set geen gerelateerde records heeft, krijg je die foutmelding. Ik kan me vergissen, maar ga het nu even niet uitzoeken, het is zaterdag.

Wat een inzet voor de goede zaak! :wink:

 

Heb het ooit een keer doorgegeven in mijn support tijd. Maar kreeg als antwoord dat dit "not a bug" and "expected behaviour" was.

De grens daartussen is vaag en voor discussie vatbaar.

 

Error handling in FileMaker is dringend aan vernieuwing toe, je hebt gelijk dat je dit aan de kaak stelt.

Wat ik o.a. mis:

O, maar ik heb niet echt veel te klagen.

 

1. Error levels: zoals hier het geval is, er is inderdaad iets aan de hand, maar het is geen kritische fout, dit heb je ook in exit loop script steps, en dit maak de "pauze on error" feature eigenlijk zo goed als nutteloos. Ik zet tegenwoordig "exit loop if Get ( CurrentRecordNumber ) = Get ( FoundCount )" vlak voor "go to record/request next [exit after last]". Om het server log niet te flooden, want in server side scripts wordt dit anders ook nog eens gelogd.

Ja, lachen die server logs. Zelfs een venster scriptstap die genegeerd wordt komt als error in de lijst.

 

2. Echte error handling. De "Set error capture" script stap uitgebreid, of een nieuwe script stap "Set error handling script". Waar je dus in terecht komt als het fout gaat, met nuttige parameters beschikbaar in dat script. Je hoeft dan niet achter elke script lijn 3 of 4 extra lijnen te schrijven om een mogelijke error conditie op te vangen.

Mmm, de code raakt dan over meer scripts verspreidt en voor de meeste gebruikers wordt het ondoorgrondelijk. Afhandelen binnen het script vind ik wel netjes en prettig. En wat er bij een fout gedaan moet worden hangt toch weer van de scriptstap af die een probleem ondervond. Voor een eenvoudige melding kan je natuurlijk een subscript gebruiken.

Zolang er nog mensen zijn die databases maken en helemaal geen foutafvanging doen, ligt daar de grootste uitdaging.

 

3. Meer error codes. Als ik een "import file" script stap gebruik, dan kunnen er "on runtime" meerdere errors voorkomen. De import kan mislukken, ik kan de keuze van de te importeren file annuleren, ik kan het openen van een gerelateerde file annuleren ( gebeurd wanneer de import interactief is ). De laatste 2 errors hebben als waarde "1". Gebruiker annuleerde. Niet genoeg. De ene is kritisch, de andere mogelijk niet.

Mee eens. Aan '1506: E-mailbericht(en) is(zijn) niet verzonden' heb je helemaal niets. En bij records importeren meer informatie over bij welk veld en welk record het probleem optrad.

Echte programmeeromgevingen vermelden in de documentatie van de functies ook welke foutnummers je kan verwachten, da's ook handig.

 

4. Volledige error capturing. Als bijvoorbeeld de connectie met een file verloren gaat, wil ik dat in software opvangen, en geen dialoog krijgen. Belangrijk voor robots en niet attente of "minder technisch aangelegde" gebruikers.

Als FM het verbreken en opnieuw verbinden goed afhandelt hoef je dat toch helemaal niet te weten in je scripts? Je kan dit eenvoudig oplossen door het scripts in de database te laten noteren wanneer het voor het laatst gedraaid heeft en daar een script op te laten reageren met melding bij inloggen, e-mail o.i.d. Eventueel een server-script maar wat als de script engine zelf een keer vastloopt? :D

 

5. Error handling voor formules.

Bijvoorbeeld:

Set Field [ Untitled::field ; 1/0 ] 
Show Custom Dialog [ Get ( LastError ) ] 

Zal geen foutcode geven. Omdat de foutcode die van de "Set Field" instructie is. Nochthans doen we hier iets dat eigenlijk zou kunnen opgevangen worden. Get ( LastCalculationError ) ? Ver gezocht? Wat bijvoorbeeld met situaties? situaties waar een plug-in niet geladen is. We hebben op het ogenblik een knullig EvaluationError ( Evaluate ()) om zo'n dingen heel proactief te gaan opvangen. Dat wil ik echt niet overal gaan implementeren.

Dergelijke fouten door onjuiste data zijn vooraf te controleren en formeel doet de scriptstap het goed. 'field missing' is te verhelpen door af en toe een DDR te draaien en te doorzoeken hoe klungelig dat misschien ook is. Bij verwijderen van een veld krijg je bovendien een waarschuwing als het veld nog in een script gebruikt wordt (behalve in import/export/sorteer volgordes...).

Vooraf controleren of de juiste plug-in er is lijkt me een uitgemaakte zaak.

Ik vertel je niets nieuws maar blijkbaar vind jij dat niet voldoende?

 

Mvg,

René

Link naar reactie
Dat het huidige record geen gerelateerd record heeft doet dan niet ter zake omdat het niet vereist is/gevraagd wordt.
In jouw perceptie zal dat ongetwijfeld correct zijn, maar niet in de mijne.

 

Als er geen enkel gerelateerd record wordt gevonden gevonden krijg je fout 401.
Zie je wel, ik wist dat ik er een vergeten was :idea:

 

Hé!? Vreemde redenering. FM zoekt per record in de index de bijbehorende records en verzamelt die in een lijst van record ID's. Het weet in dat proces meteen of er een record geen gerelateerde records heeft.
Nee dat geloof ik niet, ik denk FM nu alleen maar "weet" welke child-records er bij de gevonden set horen en hij "weet" welke records er bij het actieve record horen. Zo komt hij namelijk tot zijn fout 0 of 101.

 

Zelfs als het een intersectie van twee verzamelingen sleutelvelden maakt, gezien de traagheid bij veel records lijkt het daar niet op, dan maakt het niet uit hoeveel gerelateerde records er precies worden gevonden.
Jouw uitgangspunt blijft duidelijk dat het jou alleen uitmaakt of de gevonden set als geheel child-records heeft en individuen doen er wat jou betreft niet toe. Dan kan je net zo goed de foutcode 101 voortaan negeren en na GTRR checken of je een resultaat hebt oid.
Link naar reactie
Zelfs als het een intersectie van twee verzamelingen sleutelvelden maakt, gezien de traagheid bij veel records lijkt het daar niet op, dan maakt het niet uit hoeveel gerelateerde records er precies worden gevonden.
Jouw uitgangspunt blijft duidelijk dat het jou alleen uitmaakt of de gevonden set als geheel child-records heeft en individuen doen er wat jou betreft niet toe. Dan kan je net zo goed de foutcode 101 voortaan negeren en na GTRR checken of je een resultaat hebt oid.

 

Het is toch vreemd dat de programmeur bij normale werking van een scriptstap een foutmelding moet negeren? Begrijp me goed, als de optie 'Overeenkomst met alle record in huidige gevonden reeks' uit staat vind ik het logisch dat er een foutmelding komt als het record geen gerelateerde records heeft. Maar zodra die optie aan staat zou er alleen een foutmelding moeten komen als er geen enkel gerelateerd record wordt gevonden. Records zonder gerelateerde records zijn op andere wijze eenvoudig op te sporen.

 

Veel mensen zullen dit niet weten en als bij maken/testen van het script er toevallig geen probleem optreedt dan kan het bij het gebruik toch mis gaan. Dan worden bv. de gerelateerde records niet bijgewerkt, geëxporteerd enz. In mijn opleiding heb ik geleerd dat zoiets slordig is.

 

Mvg,

René

Link naar reactie
Veel mensen zullen dit niet weten en als bij maken/testen van het script er toevallig geen probleem optreedt dan kan het bij het gebruik toch mis gaan. Dan worden bv. de gerelateerde records niet bijgewerkt, geëxporteerd enz. In mijn opleiding heb ik geleerd dat zoiets slordig is.
En dus vind ik het logisch dat je de foutcode 101 krijgt wanneer het actieve record geen child-records heeft bij GTRR, terwijl de rest dat wél heeft. Ik ben het daarom wél met je eens dat er eveneens een foutmelding zou moeten worden gegeven, wanneer een willekeurig ander record geen child-records heeft.

 

Dat laatste is echter niet zo omdat de originele functie GTRR (pre-FM8) alleen maar GTRR van het actieve record deed. FMI heeft die foutcontrole nooit gebouwd, maar daarom is de 101-fout zoals jij hem beschrijft dus niet onterecht.

 

Ik denk dat FMI het bewust weg heeft gelaten vanwege de snelheid en dat het geen vergissing is. Jij vind dat dus niet, omdat het, volgens jou, een bekend gegeven is bij het uitvoeren van GTRR en, volgens jou, géén vertraging oplevert, waarbij, volgens jou, het aantal moeder-records om het even is.

 

We denken er dus allebei anders over, nou prima, toch? :D

Link naar reactie
Ik denk dat FMI het bewust weg heeft gelaten vanwege de snelheid en dat het geen vergissing is. Jij vind dat dus niet, omdat het, volgens jou, een bekend gegeven is bij het uitvoeren van GTRR en, volgens jou, géén vertraging oplevert, waarbij, volgens jou, het aantal moeder-records om het even is.

 

We denken er dus allebei anders over, nou prima, toch? :D

Ga nou niet een beeld scheppen alsof het allemaal mijn meningen zijn en jij de ratio hebt. Misschien denk ik wel het omgekeerde maar zeg ik dat uit beleefdheid niet.

 

René

Link naar reactie

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.

Gast
Antwoord op deze discussie...

×   Geplakt als verrijkte tekst.   Plak in plaats daarvan als platte tekst

  Er zijn maximaal 75 emoji toegestaan.

×   Je link werd automatisch ingevoegd.   Tonen als normale link

×   Je vorige inhoud werd hersteld.   Leeg de tekstverwerker

×   Je kunt afbeeldingen niet direct plakken. Upload of voeg afbeeldingen vanaf een URL in

×
×
  • Nieuwe aanmaken...