Bij zoeken op europese datum resultaat op US datum

In een grote dB gebruik ik op een bepaald formulier een invulveld voor een datum die niet wordt opgeslagen en een bijbehorende knop opent een ander formulier met de gewenste record dat bij die datum hoort.
Ik weet welke data in de onderliggende tabel voorkomen en het lijkt ook prima te werken voor bijv. data als 21-6-2018 en 25-06-2018. Echter data als 5-6-2018 en 11-6-2018 krijg ik geen resultaat. Uren zitten zoeken waar de verschillen in de records zouden kunnen zitten zonder resultaat.
Bij het proberen van nog meer data die in de tabel voorkomen krijg ik bij toeval een resultaat voor 1-5-2018. Dat is echter een record met datum 5-1-2018 wat het geopende formulier ook vermeld, inderdaad een bestaande record voor die datum, maar niet de gezochte.
Nu heb ik alle velden standaard ingesteld op korte datumnotering, daar zit geen verschil.
Vreemde is dat als ik zoek op een datum die niet verkeerd te interpreteren is, dus een getal voor datum bevat groter dan 12 gaat het goed maar zodra een datum zowel een Europees formaat als ook een US formaat kan zijn gaat het fout.

Iemand hier een verklaring voor?

NB:
Ik werk wel met een thin client op een server

Johgs zei:

Uren zitten zoeken waar de verschillen in de records zouden kunnen zitten zonder resultaat.

Klik om te vergroten...

En toch is het probleem logisch verklaarbaar; sterker nog: je doet dat al in de titel van je vraag. De reden dat een datum als 26-7-2018 goed gaat, en 2-7-2018 niet is, zoals je al constateerde, omdat 26 groter is dan 12 en 2 niet. Ik ken je code niet die je gebruikt, dus een complete oplossing kan ik je niet geven (vraag je ook niet, je wil een verklaring ), maar de verklaring zit 'm dus in het feit dat jij een Europese datumnotatie gebruikt, en je code een Amerikaanse. Daarbij staat de maand vooraan, gevolgd door het dagnummer, en dus niet, zoals bij ons, het dagnummer gevolgd door het maandnummer. Omdat een maand maar 12 maanden kent, zal elke datum vanaf de 13e dus goed gaan, omdat er nu eenmaal geen dertiende maand is (althans: niet voor computers).

Je hebt als mogelijke oplossing de datumnotatie verandert, maar dat doet natuurlijk geen zier, omdat de datum is een getal dat nog steeds hetzelfde is. Dat getal verandert namelijk niet door de notatie te veranderen. Tot zover de verklaring. Maar eigenlijk wist je dat al, gezien de vraagstelling.

Om je toch een beetje de goede kant op te duwen: de oplossing is eigenlijk simpel. Je moet je zoekfunctie zodanig aanpassen dat hij de datum niet als Amerikaans ziet, maar puur als versieonafhankelijke datum. Zelf doe ik dat op een relatief simpele manier: ik converteer de datum daarom altijd naar een getal terug. Zoals ik al aangaf: dat getal blijft hetzelfde, alleen de weergave ervan zorgt voor een verkeerde interpretatie. Omdat je een datum niet met een getal kan matchen in een filter, moet je ofwel van je filterveld óók een getal maken, ofwel dat omgewerkte getal in de query weer converteren naar een datum. Beide varianten werken prima.

Ah, ik weet dat een computer met een getal rekent ipv met een datum zoals wij die zien maar had verwacht dat Acces een Europese datum als 02-06-2018 als getal 42523 zou zien terwijl 02-06-2018 als US datum als 43137 gezien zou worden, maw woorden dat Access zou kijken naar het formaat dat ingesteld is bij invoer. Blijkt dus dat dat wel bij invoer gebeurd maar niet bij uitlezen door de code. Lijkt me toch een tekortkoming van Access.

Vreemde is wel dat in de dB aardig wat zoekfuncties op datum zitten die tot nu toe al jarenlang het juiste resultaat geven, wel aangemaakt met een oudere Access versie.
Zal eens zien, wellicht heb ik die velden als tekstveld en voor invoer een datumsjabloon en als datum als tekst gelezen wordt dan zou zoeken wel altijd goed werken.

Begrijp nu gelijk waarom in sommige query's de sortering op datum niet altijd goed af- of oploopt. ;-)

Bedankt weer.

Johgs zei:

Lijkt me toch een tekortkoming van Access.

Klik om te vergroten...

Je haalt een paar zaken door elkaar; dit is absoluut geen tekortkoming van Access, maar een gevolg van de onderliggende architectuur, waarbij programmeren nu eenmaal met Amerikaanse API's werkt, en je dus moet zorgen dat je de juiste data aanlevert in je code. Door de (correcte) datum om te zetten naar een getal dus. Dat zoekfuncties prima werken is ook logisch, omdat je dan weer geen VBA op de achtergrond gebruikt. Ik doe het dus zo (dummy voorbeeldje, mijn pc ligt op zijn gat dus ik kan niks doen nu)
En dat werkt dus als een tierelier: de datum wordt nu bij het uitvoeren van de query pas teruggeconverteerd. Dat uitvoeren gebeurt in de lokale versie, en dan heb je dus de juiste datum.

Ik kan op het moment helaas niet kijken hoe ik het voorheen deed. Ik moet Access op een thin client opstarten via een Citrix receiver, zodra ik maar een menuknop in het openingsscherm aanklik crasht Access. Dezelfde file gestart in runtime draait als een tierelier. Vanochtend weer wachtwoord moeten wijzigen, lijkt erop dat één en ander weer eens niet goed synchroniseert, maandag maar eens kijken. Vermoed dat ik het voorheen deed via een apart formulier met in het datumveld een verwijzing = is gelijk aan zoekveld op menupagina. Nu gebruikte ik de macrofunctie die aangeboden wordt bij aan aanmaken van een knop en keuze zoek bepaalde gegevens (wizard functie).

Toch blijf ik het vreemd vinden dat data die in US notering niet bestaan (dus maand boven 12) wel goed omgezet worden en geen foutmelding geven dat die datum niet bestaat.

Bij de start met Access loste ik veel problemen op met voor alles een apart formulier gebaseerd op een tabel en directe verwijzingen. Nu veel meer met hetzelfde formulier gebaseerd op een query met meerdere tabellen, een bepaalde naam wordt nu ook niet meer in de tabel gezet maar enkel een iD, scheelt een hoop ruimte in de tabellen en een spelling kan aangepast worden zonder de oude spelling kwijt te raken in overzichten. Veel voordelen en naar nu blijkt ook (gelukkig kleine en oplosbare) nadelen.

Johgs zei:

een bepaalde naam wordt nu ook niet meer in de tabel gezet maar enkel een iD, scheelt een hoop ruimte in de tabellen en een spelling kan aangepast worden zonder de oude spelling kwijt te raken in overzichten.

Klik om te vergroten...

Dat zou één van de zaken moeten zijn die je als eerste leert als je databases gaat bouwen .

Tsja, nooit geleerd gewoon gaan doen. Het begon heel simpel met een heel simpel doel en begon toen te groeien. ;-)

Beter laat geleerd dan nooit .

Het leren valt wel mee, wat tegenvalt is het snelle vergeten.

Da's een kwestie van leeftijd vrees ik. Boven de 18 loopt dat snel terug .