kleine frustratie... en het moet eruit :)

[andries]

Wat is het nut van een type "Datum" veld als FileMaker de data toch niet uniform opslaat. (zelfde voor timestamp en time)

 

nu moet je altijd GetAsDate ( Self ) in de datumvelden invullen als auto-enter... anders kan je voor 2 keer dezelfde datum "1/09/2015", "01/9/2015", "01/09/2015", ... hebben.

 

intern werkt alles wel, maar als je een export doet zien de mensen wel degelijk dat de datums anders zijn ingevoerd... lijkt me toch logisch dat FileMaker dit makkelijk kan verhelpen...

[bigbadwolf]

Zo had ik ’m nog niet bekeken, maar dat ziet er inderdaad niet logisch uit.

Misschien dat ze daarom bij het exporteren de optie gegeven hebben om gebruik te maken van de opmaak van de lay-out...

[Ari]

Zo ken ik er nog wel eentje.

 

Maak een database aan in een Nederlandse fm versie en de benaming van dagen en maanden zal ten alle tijden in het Nederlands blijven ook al werk je met een Engelse versie op een Engels besturingssysteem. En andersom natuurlijk..

[rmw]

Wat is het nut van een type "Datum" veld als FileMaker de data toch niet uniform opslaat. (zelfde voor timestamp en time)

Omdat je bij de opmaak de mogelijkheid hebt om op te geven dat de datum moet worden weergegeven zoals die is ingevoerd?

Of was de vraag retorisch?

 

rmw

[andries]

weergave is iets voor mensen die graag interfaces hebben

 

ik zou graag hebben dat een databank data op een consistente manier opslaat

 

 

maar bon, heb nu ook wel door wat en waarom hij dit doet, en het ging om het feit dat ik datums als text objecten met elkaar aan het vergelijken was ... dus ik ben zelf ook wel wat schuldig aan mijn frustratie.

[hans erik]

Je zou bij de auto enter opties een mogelijkheid moeten hebben om de waarde op te slaan in een bepaald formaat.

 

En misschien niet alleen voor datums: ook getallen, qua nauwkeurigheid.

[menno]

Volgens FileMaker worden data, tijden en tijdstempels altijd opgeslagen als een getal. Data als aantal dagen vanaf 1/1/0001, tijden als seconden sinds 0:00:00 en tijdstempels als seconden vanaf "01-01-0001 00:00:01".

 

Het vervelende is dat je dan nog steeds tegen problemen kan oplopen, want op de een of andere manier wordt het lokale formaat tóch in de gegevens opgeslagen. In dit topic van freaky kan je problemen zien die kunnen onstaan zodra een bestand met meerdere invoertalen/landinstellingen wordt gebruikt. Ik heb in mijn antwoord een mogelijke oplossing beschreven voor die problemen, maar echt opgelost is het daarmee natuurlijk niet. 10 januari 2015 kan op de volgende manieren worden beschreven, bijvoorbeeld als 1-10-2015, 10-1-2015 of 2015-10-1, verder kan ipv de "-" een "/" of bijvoorbeeld een "." worden gebruikt en kan er gebruik worden gemaakt van wél of géén voorloopnullen. Dat zijn nog niet alle voorbeelden, maar het probleem lijkt duidelijk en dit geldt ook voor tijden en tijdstempels.

 

Kortom het idee om alle waarden als getal op te slaan is zo gek nog niet, maar waarom de de weergave (evenals de invoer) niet enig en alleen afhankelijk is van de weergave kenmerken van de door de gebruiker of de programmeur ingestelde eigenschappen van het systeem, de layout of het invoerveld, is me een raadsel. Op de een of andere manier worden die eigenschappen óók bij de data opgeslagen en dat zou nu eigenlijk niet moeten. Als het veld op de layout eigenschappen heeft mbt de weergave zouden die eigenschappen bij invoer en exports moeten worden gebruikt, zijn die afwezig, dan moeten de layouteigenschappen, missen die ook, dan de bestandseigenschappen en als die óók ontbreken, de systeeminstellingen.

 

In formules en variabelen maak ik veelvuldig gebruik van Date ( m ; d ; y ), Time ( h ; m ; s ), GetAsText ( date/time/timestamp ) en GetAsDate/GetAsTime(Stamp) om er maar voor te zorgen dat ik geen appels met peren aan het vergelijken ben en dat functioneert tot nog toe goed. Het is alleen wel veel werk en als ik het eens vergeet, dan onstaan er meestal snel problemen.

 

Met getallen uit scriptvariabelen heb ik ook al eens een gelijksoortig probleem gehad: "2 < 12" was volgens FileMaker FALSE! De oorzaak was echt heel simpel: de waarde "12" was een tekstwaarde! Het gevolg: de evaluatie was niet "2 < 12" maar "2 < 1". Dus met GetAsNumber ( "12" ) was het probleem opgelost. (uiteraard was de werkelijke uitvoering is iets complexer, maar de essentie was GetAsNumber ( "12" ) )

 

Ik kan me de frustratie van Andries dus heel goed voorstellen en wellicht moeten we dit eens bij FMI aankaarten en kijken of ze hier niet eens een oplossing voor kunnen implementeren

[hans erik]

Ik denk dat FileMaker gegevens over de originele invoer van een 'string' als een soort metadata vastlegt bij het veld, d.w.z. heel diep in de datastructuur. Dat is dus iets uit een heel ver verleden. FMI had dit misschien moeten veranderen in de aanpassing van FP7 naar FMP12 formaat, maar ik denk dat ze er of niet aan toegekomen zijn of het niet aangedurfd hebben.

 

Maar wat betreft de frustratie van Andries: ik ben met hem eens, maar volgens mij is het echte probleem dat FileMaker een hele aftandse import- en exportmodule heeft, die al jaren aan een grote verbetering toe is. Dit is voor een database die inzetbaar moet zijn in veel omgevingen met externe gegevensbronnen ver beneden peil. Dit doet MS Access echt veel beter

 

En om het maar meteen handen en voeten te geven, bij de import- als export scriptstappen zou je een advanced modus moeten hebben met:

- de mogelijkheid om een field delimiter aan te geven;

- een exportformaat aan te geven (decimal/thousandseparator, datum- en tijdformaat);

- de karakterset/encoding (ANSI/UTF-8 etc.);

- een oplossing voor de veldnamen in de eerste regel (dus 'productnaam' in plaats van SALES_PRTTBLE_DFT::PROD_NAME_ABBRVTED), wat ook voor export naar Excel een welkome verbetering zou zijn

 

Dus geen presets die ergens in een kantoortje in Mountain View zijn bedacht maar gewoon een volwassen en flexibele (noem het 'nerdy') oplossing. Voor import uit een andere FileMaker tabel zou ik overigens ook graag de fieldmapping met een formule willen kunnen aangeven.

 

Ik snap best dat de prioriteiten van FMI bij hippe mobiele oplossingen liggen, maar ergens zullen ze de bottomline ook moeten aanpakken. Er ligt een oceaan aan gegevens te wachten op exploratie. Big data, iemand?

 

[edit]

Ik hoor mensen al roepen: en XML dan? Ja, is prachtig maar

a. je moet toch zelf de XSL in elkaar sleutelen;

b. er zijn massa's toepassingen die (nog) geen XML ondersteunen, terwijl XML al ruim 15 jaar beschikbaar is...

 

Hans Erik