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.

[Marsau]

Is toch een kleine ramp als het klopt. 

Is die selectWeek wel een numerieke waarde? 

WeekofYearFiscal levert sowieso een numerieke waarde op, dus een getasnumer() zou niets kunnen toevoegen.

[Banach]

Een gevalletje van verkeerde types? Bij mij geven beide functies exact hetzelfde resultaat, zowel onder FM18 als ook FM19.

jaar.fmp12

[bigbadwolf]

Denk dat het probleem voornamelijk zit in het globale veld. Dat is een tekstveld.

Dit gaf voorheen nooit problemen, FileMaker ‘zag’ het als er alleen cijfers in stonden. Het lijkt erop dat je daar dus niet (meer) op kunt blindvaren…

[Banach]

Met een tekstveld krijg ik het inderdaad gereproduceerd. De oplossing is dus om van het tekstveld een nummer veld te maken. Kortom: Dit dwingt je om 'netter' te programmeren. Naar mijn mening is dat niet verkeerd.

[Marsau]

Dat zeker, maar wel een potentieel risico voor bestaande systemen, waar die accuratesse niet consequent is toegepast.

Die 'vergevingsgezindheid' of flexibiliteit om bijv een getal als tekstuele waarde toch als getal te behandelen was naar mijn gevoel typisch iets van FileMaker, zoals ook de mogelijkheid om altijd veld/tabel/script etc namen te kunnen wijzigen.

[bigbadwolf]

@Banach Mee eens, maar wat dat betreft heeft Marsau gelijk. De vergevingsgezindheid van FileMaker heeft altijd die flexibiliteit gehad, waarom dan nu ineens niet meer? En in die specifieke geval zijn er 3 globale velden die ik voor elke Custom Dialog gebruik en dat zijn allemaal tekstvelden.

[Banach]

Ach, het scheidt de jongens van de mannen, het kaf van het koren. Zelf verwacht ik deze problematiek nimmer tegen te komen maar dat komt wellicht omdat ik ooit veel in Pascal heb moeten/mogen programmeren.

[hans erik]

Kan het te maken hebben met het feit dat FileMaker in de toekomst steeds meer Javascript en andere ‘externe’ datasystemen gaat integreren? Wat in FileMaker prima kan, loopt in Javascript stuk (trouwens, in SQL ook!).

[Banach]

Dat klinkt heel plausibel. Dan is het zoiets als stiekeme bug fixing. 😀

[Marsau]

Nou ja, bug fixing? Eerder een wijziging van de spelregels. Of misschien zelfs afwijkingen van de ontwerpfilosofie. 

Een numerieke waarde als een tekst kan direct als zodanig behandeld worden, en dat is wat je zou kunnen noemen de 'intelligentie' van low-code ontwikkelomgeving, in tegenstelling tot het strikte 'autisme' van en programmeertaal.

En zoals eerder gesteld: de 'stiekeme' wijziging kan leiden tot bugs in bestaande systemen. En die zijn dan niet per se toe te rekenen aan 'incompetentie' van de ontwikkelaar.

[Banach]

Heeft men bij Claris een ontwerpfilosofie? Daar kijk ik van op. In alle jaren dat ik actief met FM bezig ben heb ik altijd gedacht dat ze maar wat aanklooien. 😂

[hans erik]

Als ze nou toch aan het fixen gaan: het is toch te zot voor woorden dat de formatteringsopties van getallen sinds FileMaker 2 niet meer verbeterd zijn. Wat bijvoorbeeld in Excel moeiteloos kan: bij een getal veld precies aangeven hoe het weergegeven moet worden. Dus 0 bijvoorbeeld als 'nil', een ontbrekende waarde als 'p.m.', een positief getal als '#.###.###,00' en een negatief getal als '(#.###.###,00)' waarbij er dus altijd 2 decimalen worden weergegeven.

Wat betreft de 'stiekeme' wijziging: op zich hebben ze wel een punt, maar ze moeten e.e.a. natuurlijk duidelijk documenteren. We worden eigenlijk als kleuters behandeld.

[Banach]

Zo concluderend kan ik stellen dat het antwoord op de vraag van BBW of FileMaker kritscher (sic) geworden is moet luiden: Niet echt, maar de developers in ieder geval wél. Ik word daar wel heel erg kritschig van.

[Roger]

Ik blijf het een bijzonder verhaal vinden. Als er een numerieke waarde in een tekstveld staat, is en blijft dit een absolute numerieke waarde en die gebruiken in calculaties zou geen andere resultaten mogen opleveren dan diezelfde waarde in een getalveld. Het lijkt mij geen gevalletje bug fixing maar eerder een bug die nog gefixt moet worden. Ik ben benieuwd naar de volgende update. 

[hans erik]

@Marsau: ik denk dat je toch in een 'professionele' omgeving moet zorgen dat je expliciet - of: bewust - om moet gaan met die 'vergevingsgezindheid' en het niet als een feature moet behandelen. Je kunt immers op de raarste momenten tegen problemen aanlopen. Neem bijvoorbeeld relaties: als je een relatie legt tussen een numeriek veld en een tekstveld, is het resultaat niet altijd wat je verwacht. En je kunt je helemaal suf zoeken naar de oorzaak... Ik zou er hoe dan ook voor willen pleiten om vrij strikt met datatypen om te gaan. Je kunt een tekstveld prima gebruiken om een getal op te slaan (als string), maar andersom zou ik toch niet doen.

@Roger: FileMaker heeft natuurlijk al jaren de GetAsNumber functie. Maar als je meerdere getallen in een tekstveld opslaat (gescheiden door returns, spaties, whatever) en je laat er een berekening op los, gebeuren er in interessante dingen...

Overigens: een feature die FileMaker in mijn optiek WEL uniek maakt zijn de superveelzijdige relaties: multi-key, multi-valued keys. Dat is met een SQL database ondenkbaar.

[hans erik]

14 hours ago, Roger said:

Ik blijf het een bijzonder verhaal vinden. Als er een numerieke waarde in een tekstveld staat, is en blijft dit een absolute numerieke waarde en die gebruiken in calculaties zou geen andere resultaten mogen opleveren dan diezelfde waarde in een getalveld. Het lijkt mij geen gevalletje bug fixing maar eerder een bug die nog gefixt moet worden. Ik ben benieuwd naar de volgende update. 

Nee, een numeriek waarde in een tekstveld is een string die op een getal lijkt, niet meer dan dat. Als je het wilt gebruiken in een formule kun je er op vertrouwen dat FileMaker het automatisch omzet naar een numerieke waarde, maar je doet er beter aan om de getAsNumber functie te gebruiken, al dan niet in combinatie met controles op punten en komma's e.d. Maar ik zou wel graag optioneel een 'locale' toegevoegd willen zien aan de getAsNumber functie (en de executeSQL). Zodat je kunt aangeven hoe FileMaker met de getalnotatie om moet gaan.

[Marsau]

1 uur geleden zei hans erik:

@Marsau: ik denk dat je toch in een 'professionele' omgeving moet zorgen dat je expliciet - of: bewust - om moet gaan met die 'vergevingsgezindheid' en het niet als een feature moet behandelen. Je kunt immers op de raarste momenten tegen problemen aanlopen.

Begrijp me goed, Hans Erik. Ik heb helemaal geen problemen met de strikte, exacte benadering.  Maar wat ik denk:

a. dit FileMaker gedrag (versie <19? ) is ooit ontworpen; was geen bug, maar 'intended to be', als onderdeel van een poging een superflexibele ontwikkelomgeving neer te zetten ('Apple'-like, zou ik haast zeggen);

b. Deze feature werkt nu - zoals het nu schijnt, zonder enig tamtam - niet meer. Gewijzigde spelregels zou je kunnen zeggen, en daarmee kunnen fouten ontstaan als 1001 bloemen voor degenen die er tot nu toe achteloos gebruik van hebben gemaakt.

Neemt niet weg dat ik verder geen enkel bezwaar heb tegen deze wijziging. 

Hypothetisch voorbeeld: stel men besluit om bij logische waarden (true/false of '1'/'0') true niet meer te laten samenvallen met getallen n > 1, o.i.d. Dan zijn de rapen gaar. 

 

[Roger]

1 uur geleden zei hans erik:

Nee, een numeriek waarde in een tekstveld is een string die op een getal lijkt, niet meer dan dat.

Hoe zit dat dan met variabelen? Deze worden altijd als alfanumeriek opgeslagen.

Ik werk vrij veel met multi-value-key velden. Die zijn zover ik weet uitsluitend mogelijk met tekstvelden. Ik wist niet dat dit FM uniek was maar vind dit toch wel een heel prettige functie die ik niet graag zou missen en waar ik wel op wil kunnen blijven vertrouwen.

[menno]

Ik heb eventje gecontroleerd of er in FM inderdaad iets zou zijn gewijzigd mbt tekst die "automagisch" als getal zou worden behandeld. 

Ik heb in de screenshots hieronder overal dezelfde getallen en teksten gebruikt.

Het probleem dat je hier krijgt is "waarneming", de getallen en teksten worden door ons mensen vaak niet goed geïnterpreteerd.

"6" > "3" maar "16" < "3" en dat komt omdat de getallen door de aanhalingstekens tekst zijn geworden.

Bij tekst in een berekening wordt altijd en alleen maar het eerste karakter van de tekst als getal gebruikt. Kijk je met die bril naar de berekeningen hieronder, dan kloppen en begrijp je ook de uitkomsten.

Je kan gerust stellen dat er geen verschil is tussen FM13, 18 en 19 en er is ook geen verschil tussen MacOS en Windows. De bottomline is dat je appels niet met peren moet vergelijken of zoals mijn oud-collega Jos zei: Je moet Apple niet met Windows willen vergelijken  

[menno]

1 uur geleden zei Roger:

Hoe zit dat dan met variabelen? Deze worden altijd als alfanumeriek opgeslagen.

Als je een variabele declareert, dan is het automatisch het juiste formaat. Bijvoorbeeld:

Let ( [ 
	$getal = 145,7 ; 
	$datum = Date ( 2 ; 11 ; 2021 ) ; 
	$tijd = Time ( 12 ; 0 ; 0 ) ; 
	$tekst = "Een verhaal" ; 
	$container = Tabel::Containerveldnaam 
] ; 
	"" 
)

Al de bovenstaande variabelen hebben in dit geval het formaat van het resultaat van de formule waar ze zijn gedeclareerd. Maak je echter een datum als volgt:

Let ( [ 
	$datum = "11-2-2021" 
] ; 
	"" 
)

Dan is het tekst en geen datum. Dus als je ergens in je script een variabele bewerkt of omzet, moet je gewoon opletten welk formaat de variabele heeft en zou moeten hebben. Dat moet eigenlijk je tweede natuur zijn.

1 uur geleden zei Roger:

Ik werk vrij veel met multi-value-key velden. Die zijn zover ik weet uitsluitend mogelijk met tekstvelden. Ik wist niet dat dit FM uniek was maar vind dit toch wel een heel prettige functie die ik niet graag zou missen en waar ik wel op wil kunnen blijven vertrouwen.

Multikeys zijn altijd tekst, maar dat hoeft geen probleem te zijn bij het leggen van relaties. Je kan een tekst gerust koppelen met een getal, zolang de waarde die voor de relatie wordt gebruikt, maar wel een getal is. FileMaker is wat dat betreft behoorlijk vergevingsgezind en naar mijn smaak een beetje té vergevingsgezind.

Ik heb bij klanten serienummervelden gezien die in het serienummer DEB000024 hadden staan. Hun redenatie: het is een serienummer, dus het moet een getal-veld zijn. Gek genoeg werkte het ook nog, maar ExecuteSQL() gaat bij zulke "overtredingen" niet lekker werken. 

[Roger]

1 uur geleden zei menno:

Bij tekst in een berekening wordt altijd en alleen maar het eerste karakter van de tekst als getal gebruikt. Kijk je met die bril naar de berekeningen hieronder, dan kloppen en begrijp je ook de uitkomsten.

Ik denk dat dit de crux is in situaties waar het misgaat met calculaties. Goed om je bewust van te zijn. Dank voor je nuttige toevoegingen Menno!

[hans erik]

Quote

Ik heb bij klanten serienummervelden gezien die in het serienummer DEB000024 hadden staan. Hun redenatie: het is een serienummer, dus het moet een getal-veld zijn. Gek genoeg werkte het ook nog, maar ExecuteSQL() gaat bij zulke "overtredingen" niet lekker werken.

Ik gebruik nog steeds regelmatig serienummervelden maar altijd als tekst, d.w.z. altijd met voorloopnullen. Dan sorteren ze ook nog prima. Als je over de range heengaat voegt FileMaker een extra positie toe, al is dat natuurlijk niet de bedoeling. Overigens denk ik dat je toch heel erg moet oppassen met het koppelen van getallen aan tekstkeys. Het is ook voor je ontwerp beter om daar bewust mee om te gaan. In mijn optiek zijn getallen alleen: aantallen en bedragen (en 'boolean', omdat FileMaker geen apart type 'boolean' kent).

 

[Banach]

Dat laatste is niet helemaal waar. FileMaker kent de constanten 'True' en  'False'. Intern worden deze als '1' en '0' opgeslagen waarbij het er niet toe doet of dat een text of getalveld is.  Door de functie 'GetAsBoolean' te gebruiken kun je vervolgens niet mis gaan.

[Peter Wagemans]

Terugkomend op de originele vraag, wat ik hier absoluut niet OK vind van Claris, is dat ze zoiets niet documenteren in hun release notes.

Ik al een beetje een probleem mee dat Claris er eerst prat op gaat dat het programma zó gebruiksvriendelijk is, dat je velddtypes door mekaar mag gebruiken. Dat je dit als professionele developer echt niet mee mag beginnen, is ook waar, maar zover ik weet richt Claris zich niet alleen op professionele developers. Als Claris dat wél zou doen, dan kregen we dit te lezen in de release notes. Hé, de cirkel is rond.

[Banach]

@Peter WagemansIk ben het niet eens met bovenstaande kritiek op de documentatie. Nergens heb ik kunnen terugvinden dat men bij Claris nu of in het verleden aangeeft dat je veldtypes door elkaar mag gebruiken. Kijk bijvoorbeeld eens in de handleiding van notabene FM13: https://fmhelp.filemaker.com/help/13/fmp/nl/html/create_db.8.13.html.  Ik zie daar een duidelijke omschrijving waar ieder veldtype voor is bestemd en welke beperkingen er gelden.

Fouten welke nu naar boven komen omdat FM hier minder tolerant in is moet je m.i. echt de developer, ook de niet-pro, aanrekenen en niet Claris. We hebben het immers over oneigenlijk gebruik. Wanneer je de handleiding niet leest en 'zomaar' wat doet moet je niet raar opkijken wanneer het resultaat niet aan je verwachtingen voldoet.