Is FileMaker kritscher geworden?

[bigbadwolf]

Iedereen gebruikt wel eens variabelen (al dan niet in velden) om data te beoordelen/gebruiken in berekeningen. Daar is niets bijzonders aan.

Wat mij opvalt is dat ik sinds 19 meer ‘last’ heb van berekeningen die een andere uitkomt geven dan vroeger.

Zo liep één van mijn collega’s gisteren tegen een probleem aan wat zich voorheen nooit voordeed.

Dit is de oude code (die het tot voor kort gewoon goed deed):

Let (     
	[
	currWeek = WeekOfYearFiscal (( Get ( CurrentDate )) ; 2 ) ;
	selectWeek = DIDI::DiDi_Value1_g ;    
	currYear = Year ( Get ( CurrentDate ))
	]

	;

	Case ( 
         selectWeek < GetAsNumber ( currWeek ) 
          ; currYear + 1 
          ; currYear
          )

	)

Dit is de nieuwe versie die het wel goed doet:

Let (     
	[
	currWeek = WeekOfYearFiscal (( Get ( CurrentDate )) ; 2 ) ;
	selectWeek = DIDI::DiDi_Value1_g ;    
	currYear = Year ( Get ( CurrentDate ))
	]

	;

	Case ( 
          GetAsNumber ( selectWeek ) < GetAsNumber ( currWeek ) 
          ; GetAsNumber ( currYear ) + 1 
          ; GetAsNumber ( currYear )
          )

	)

In beide gevallen zou de uitkomt (bijv.) 2021 moeten zijn, maar de eerste code is nu van mening dat het 2022 is geworden.

Het lijkt er dus op dat het automatisch interpreteren van data (nummer, tekst, etc.) door FileMaker 19 slechter is geworden, of kritischer afhankelijk hoe je er naar kijkt. Op zich niets mis mee, maar kan wel vervelende gevolgen hebben voor bestaande situaties.

[Peter Wagemans]

@BanachWil je dan zeggen dat het dat het een bug is, die ze dan eigenlijk al lang hadden moeten oplossen?

[Banach]

Inderdaad. Zie ook de opmerking van HE mbt compatibiliteit met externe datasystemen als javascript en sql. Het kan zelfs zo zijn dat deze 'bugfix' een bijwerking is geweest bij het ontwikkelen van de javascript functionaliteit. Maar dat is pure speculatie.

[Marsau]

Ik zou het geen 'bug' noemen, eerder een frictie tussen veranderende ontwerpprincipes/vereisten. Denk dat men het destijds intentioneel zo heeft opgezet, en dat men er - zonder kennisgeving - van terug is gekomen. Ik zie geen aanknopingspunt in de aangegeven FM13-documentatie: inderdaad strikte omschrijving van de veldtypen, maar we weten allemaal dat toen wel mogelijk was wat we hier bespreken.. Pas in FM19 wordt het pas anders.

Vind het overigens geen probleem, behalve dan dat deze wijziging van de spelregels problemen kan oproepen in bestaande systemen - als je lichtzinnig met de veldtypen bent omgegaan. Vind het wat kort door de bocht om dan te suggereren dat developer dan "in gebreke" is gebleven.

Bijvoorbeeld: virtual lists. Ook onmogelijk, een relatie op basis van een ongeindexeerd veld. Vind je niet in de documentatie terug, maar de techniek werkt wel. Als het morgen opeens niet meer werkt, dan zou je dat niet gaan wijten aan de competentie van de developer ('had ie maar de documentatie moeten volgen...')

 

[Banach]

@Marsau Ik deel je mening in deze niet. Wanneer je gebruik maakt van een ongedocumenteerde feature moet je m.i. niet raar opkijken wanneer het plots niet meer werkt. Men kan bij Claris onmogelijk een nieuwe versie uitbrengen waarbij de werking van zeer inventieve oplossingen van derden gegarandeerd is. Vroeg of laat zul je dan immers vastlopen in het ontwikkelen van nieuwe FM versies . Dus moet je ver voor die tijd mogelijke beren op de weg opruimen. We mogen dan nog van geluk spreken dat men dat bij Claris, al dan niet met opzet, stapsgewijs doet. Foute keuzes vanuit het verleden moet je niet coûte que coûte hoeven meeslepen.