Ga naar inhoud
  • 0

Is FileMaker kritscher geworden?


bigbadwolf

Vraag

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.

Link naar reactie

Aanbevolen berichten

  • 0

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.

Link naar reactie
  • 0

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.

Link naar reactie
  • 0

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.

Link naar reactie
  • 0

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. 

Link naar reactie
  • 0

@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.

Link naar reactie
  • 0
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.

Link naar reactie
  • 0
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. 

 

Link naar reactie
  • 0
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.

Link naar reactie
  • 0

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.

Berekening in FM 13v9 op windowsBerekeningen in FM 19v2 op windowsBerekeningen in FM 18v3 op MacOS

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 :-) 

Link naar reactie
  • 0
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. 

Link naar reactie
  • 0
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!

Link naar reactie
  • 0
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).

 

Link naar reactie
  • 0

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.

Link naar reactie
  • 0

@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.

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
Beantwoord deze vraag...

×   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...