[ASP] datum invoer anders dan datum in database

[Verwijderd]

Wanneer ik in mijn ASP pagina een datum invoer in de vorm dd-mm-yy oftwel bijvoorbeeld 08-10-02 dan wordt dit in de (access) database omgedraaid naar mm-dd-yy oftewel 10-08-02. Mijn computer heeft een nederlands regio instelling.

Wanneer ik in access kijk naar het input mask van de datum dan is dit ook gewoon een nederlandse notatie. Ook in mijn ASP pagina gebruik ik Session.lcid=1043. En toch draait ie dus de datum om.

De server waar IIS draait heeft ook als regionale instellingen Dutch(standard). Wat zou er aan de hand kunnen zijn? Zijn er instellingen in IIS die nog aangepast zouden kunnen worden?

PS. De SQL-string geeft nog wel de juiste notatie: 08-10-02 pas daarna wordt er dus blijkbaar een conversie gedaan.

[Janoz]

Wat gebeurt er als je 31 januari invoert? Dan weet je of het bij het invoeren of bij het uitvoeren mis gaat (er is immers geen 31ste maand)

[Verwijderd]

Dan doet hij het wel, en sterker nog dan doet ie het ook goed. Dus het komt er op neer dat wanneer de eerste twee digits groter dan 12 zijn gaat het goed en wanneer deze kleiner of gelijk zijn aan 12 dan draait ie de dag en maand dus om.

[Verwijderd]

tis volgens mij een SQL standaard...
zou dus de date ff naar mm-dd-yyyy omzetten in ASP

[Verwijderd]

Ja maar dat is nu juist niet de bedoeling. Men is hier op het werk gewend aan de invoer in de nederlandse notatie, ze zijn niet echt in staat om dit anders te gaan doen.

[Janoz]

idd.. Zie iruoy.. Het werkt allemaal goed, je moet alleen in je sql commando gewoon de En notatie gebruiken. Is er trouwens neit een soort dateformat waardoor je dit onafhankelijk van de regio instellingen kunt doen? (het invoeren en het uitvoeren?)

[Janoz]

Verwijderd schreef op 08 oktober 2002 @ 11:28:
Ja maar dat is nu juist niet de bedoeling. Men is hier op het werk gewend aan de invoer in de nederlandse notatie, ze zijn niet echt in staat om dit anders te gaan doen.

Je gebruikers hoeven dat niet te doen, dat kun je toch ook wel met je ASP doen?

[Verwijderd]

Dat is waar. Maar dan nu het werkelijke probleem. Dit probleem heb ik pas sinds afgelopen vrijdag. Daarvoor ging het altijd goed. Ik ben dus bang dat in de toekomst sporadisch het systeem weer werkt, alleen dan zal mijn script dus de dag en maand verwisselen terwijl ze dan wél goed zouden zijn. Snap je het nog?

[Verwijderd]

Verwijderd schreef op 08 oktober 2002 @ 11:28:
Ja maar dat is nu juist niet de bedoeling. Men is hier op het werk gewend aan de invoer in de nederlandse notatie, ze zijn niet echt in staat om dit anders te gaan doen.

Wij doen het meestal zo:

op de ASP Pagina zetten we een input field neer die met een heel fijn stukje Regular Expression helemaal wordt gecontroleerd. Dan wordt deze in een ASP Functie voor het in de database neerzetten veranderd van dd-mm-yyyy naar mm-dd-yyyy (goede format is dd-MM-yyyy anders krijg je minuten ipv maanden)
die wordt in SQL Statement gepropt en database vind het fijn....

Zo ben je onafhankelijk van int. instellingen

[Verwijderd]

jumbolambo, wat is er veranderd sinds vrijdag? SQL Statement, Server, database

[DukeMan]

wat je ook kan doen, dat doe ik eigenlijk meestal: is in asp je datum formaat omzetten naar een string: bijvoorbeeld 08-10-02 wordt 20021008. Dit is dat een string die je in je database wegzet. werkt makkelijk en je kan er eventueel makkelijk mee sorteren...

[CmdrKeen]

Dit format werkt altijd: bv. 12 januari 2002: 12-jan-2002. Let alleen op de maanden die in 't Engels anders gespeld worden dan in 't Nederlands, zoals okt-oct.
Als je het goed wilt doen, lees dan deze tekst van 4GuysFromRolla.

Sla data altijd op in een DATUM-veld en NOOIT als cijfer- of lettercode, zoals hierboven gesuggereerd. Dat lost misschien je directe probleem op, maar maakt het lastig als je wat meer met de data wilt doen, zoals bv. controleren of de datum kan bestaan, sorteren op alleen zondagen, enz..

[Verwijderd]

Vilenin schreef op 08 oktober 2002 @ 12:31:
Sla data altijd op in een DATUM-veld en NOOIT als cijfer- of lettercode, zoals hierboven gesuggereerd. Dat lost misschien je directe probleem op, maar maakt het lastig als je wat meer met de data wilt doen, zoals bv. controleren of de datum kan bestaan, sorteren op alleen zondagen, enz..

Idd, of een hele simpele, je zult altijd moeten voorkomen dat mensen fijn 1-1-2002 of 1-1-02 gaan neerzetten......

[Theguide]

Je moet in je code de datum omzetten naar het formaat: month/day/year
SQL voorbeeld:

code:

insert into table (Date) values ('12/31/2002')

Werkt altijd met een access database.

[CmdrKeen]

Theguide schreef op 08 oktober 2002 @ 13:43:
Werkt altijd met een access database.

Umm... nee.
Dat is afhankelijk van de landinstelling van je server.

[Scharnout]

Zoals de gids hierboven al zegt:

Het allermakkelijkst is natuurlijk de invoer onafhankelijk maken van je databaseformaat. Dus gewoon de mensen op hun oude vertrouwde manier laten invoeren en dan netjes je datum opbouwen.

pseudo:

ASP:

invoer dagnummer (vb 2)
invoer maand (vb 3)
invoer jaar (vb 2002)

en dan zo __-__-____ laten zien natuurlijk

verder in je code die de input processt (oei anglisisme) doe je:

ASP:

datumstring = request.form("maand") & "/" & req("dag" enz
Cdate(datumstring)

en dan kan je hem zo de database inknallen

simpel

bij mysql doe je het jaar voorop, dan maand enz ...

oh ja voorloopnullen kan je het makkelijkst met dit doen:

ASP:

dagnummer = right("0" & request.form("dagnummer"), 2)

Access is afhankelijk van de landinstellingen van je server misschien, maar bv bij MySQL maakt dat niet uit. Daar is het altijd! yyyy-mm-dd. ALTIJD!

[Theguide]

Vilenin schreef op 08 oktober 2002 @ 13:52:
[...]


Umm... nee.
Dat is afhankelijk van de landinstelling van je server.

Dat zou je inderdaad denken, maar ik heb gelezen dat dat dus niet uitmaakt. Access probeert eerst altijd de amerikaanse datum format. Als die notatie niet kan (bijv. bij 31/12/2002), dan probeert access pas andere datum formats.

Ik heb op onze server de landinstellingen aangepast, maar dat mocht niets baten. Dit euvel bleef.
Bovendien is het natuurlijk ook beter dat er een bepaalde vaste format is. Anders is je ASP software afhankelijk van de landinstellingen van een server... niet echt compatible dus.

[Morpheus_at_work]

CID instellen bovenin de pagina

[Basszje]

okee *ASP RAMP *

het ligt aan de taalinstellingen van de volgende componenten :
ASP / ADO / ACCESS / COMPUTER . Dus CID, of Locale setten helpt niet.

Als je database op Amerikaans staat wordt alles botweg Amerikaans en dan gaat het fout zoals je al zei.

Een goede remedie is idd de maand als korte tekstnotatie te inserten (en dan converteren oid ) Dat kan gewoon met de datum functies van ASP. Op die manier gaat de server niet meer de fout in .

Ik gebruik zelf vaak een 'pseudo' timestamp . De tijd vanaf moment 0 ( 1899 ) , dat werkt goed, maar niet als je moet queren op bep. datums ( verjaardagskalender bv kan dan niet ) . Verder werkt het wel uitstekend en op elke server hetzelfde .

Ga je het anders oplossen of via Locales e.d. sla dan al vast een goede dosis valium in .

Trouwens het is wijselijk om alle datum conversie van de hele app op 1 plaats te doen. Als het niet goed gaat/ Je wilt iets anders hoef je niet je hele app door te ploegen

[CmdrKeen]

Theguide schreef op 08 oktober 2002 @ 13:59:
[...]


Dat zou je inderdaad denken, maar ik heb gelezen dat dat dus niet uitmaakt. Access probeert eerst altijd de amerikaanse datum format. Als die notatie niet kan (bijv. bij 31/12/2002), dan probeert access pas andere datum formats.

Ik heb op onze server de landinstellingen aangepast, maar dat mocht niets baten. Dit euvel bleef.
Bovendien is het natuurlijk ook beter dat er een bepaalde vaste format is. Anders is je ASP software afhankelijk van de landinstellingen van een server... niet echt compatible dus.

Vilenin spreekt uit een rijke ervaring van hoofd-muur-encounters met datum-invoer in ASP...

[Basszje]

Theguide schreef op 08 oktober 2002 @ 13:59:
[...]


Dat zou je inderdaad denken, maar ik heb gelezen dat dat dus niet uitmaakt. Access probeert eerst altijd de amerikaanse datum format. Als die notatie niet kan (bijv. bij 31/12/2002), dan probeert access pas andere datum formats.

Uhm volgens mij niet hoor . Als je nederlandse IIS / ASP en Nederlandse access gebruikt dan hapt ie echt alles Nederland hoor.

3-08 = 3 Augustus

Maar als je Access engels is, dan wordt dat dus 8 Maart.

[Theguide]

Zal wel weer een onvoorspelbare actie van micro$oft producten zijn dan.... Want ik heb toch ZEKER TE WETEN een nederlandse versie van access (waar dus de .mbb in gemaakt is). Op de server staat niet eens access (waarom zou je). Op de server staan de landinstellingen op NEDERLANDS. Maar ik moet toch echt de datum 'mm/dd/yyyy' zo invoeren, anders komt het er omgekeerd uit!
Waar het wellicht aan kan liggen: de server heeft wel een engelstalige windows, dus waarschijnlijk is die access driver in het engels/amerikaans. Maar feit blijft dat de landinstellingen er dus geen ruk mee te maken hebben. Wellicht wel de taal van het OS.

[DukeMan]

Idd, of een hele simpele, je zult altijd moeten voorkomen dat mensen fijn 1-1-2002 of 1-1-02 gaan neerzetten......

Je controleert dan natuurlijk de input en zorgt ervoor dat dag en maand 2 karakters zijn en jaar 4. Dan werkt het perfect..

[Verwijderd]

Datum invoeren als STRING, anders ziet Access het als een rekensom die uitgerekent wordt voordat deze als waarde in de tabel gestampt wordt

[Basszje]

Theguide schreef op 08 oktober 2002 @ 14:57:
Zal wel weer een onvoorspelbare actie van micro$oft producten zijn dan.... Want ik heb toch ZEKER TE WETEN een nederlandse versie van access (waar dus de .mbb in gemaakt is). Op de server staat niet eens access (waarom zou je). Op de server staan de landinstellingen op NEDERLANDS. Maar ik moet toch echt de datum 'mm/dd/yyyy' zo invoeren, anders komt het er omgekeerd uit!
Waar het wellicht aan kan liggen: de server heeft wel een engelstalige windows, dus waarschijnlijk is die access driver in het engels/amerikaans. Maar feit blijft dat de landinstellingen er dus geen ruk mee te maken hebben. Wellicht wel de taal van het OS.

Ik heb in het verleden ook wel eens last gehad van een Engelse ADO module / ODBC Driver , met nederlandse server en Nederlandse Access .

Moraal van dit verhaal : Of gebruik het niet of sluit elke mogelijke fout uit of "you're entering a world of pain"