[ASP & SQL] Opslaan en lezen van datum gaat fout

Pagina: 1
Acties:
  • 119 views sinds 30-01-2008
  • Reageer

  • Mottebelke
  • Registratie: Juni 2001
  • Laatst online: 13-08 16:52
Ik heb een datum opgeslagen in een database (SQL Server, en de datum wordt opgeslagen in het type datetime).

Deze datum wil ik uitlezen in een textfield zodat deze te bewerken is. Na deze bewerking moet de datum dan weer worden opgeslagen.

Het uitlezen van de datum gaat gewoon goed, maar als ik de datum bewerk en opsla worden de maand en dag omgewisseld. Dus ik voer bv. in 8-7-2003 en die wordt dan opgeslagen als 7-8-2003.
En ten tweede kan ik geen data opgeven die hoger zijn dan 12-12-**** (Dus 13-12-2003 gaat niet, en 12-13-2003 ook niet). Dan geeft ie namelijk een foutmelding dat de 'conversion' niet goed is gegaan, oftewel het is een foute datum.
Voor het invoeren van de datum gebruik ik de DateValue functie om de string om te zetten naar een geldig date formaat.

Wie weet hoe ik dit op moet lossen? Het lijkt me misschien iets wat met de landeninstellingen te maken heeft, maar zeker weten doe ik het niet.

  • justmental
  • Registratie: April 2000
  • Niet online

justmental

my heart, the beat

Idd. landinstellingen, je hebt ergens amerikaans staan ipv. nederlands.
Kun je geen expliciet formaat meegeven bij de conversie?

Who is John Galt?


  • Crazy D
  • Registratie: Augustus 2000
  • Laatst online: 14-08 12:38

Crazy D

I think we should take a look.

Wegschrijven als yyyy-mm-dd hh:mm (2003-07-26 15:37) levert in ieder geval geen problemen op, ongeacht de instellingen van de client, webserver, en/of database server :) Iig voor mij heeft dat altijd prima gewerkt :)

Exact expert nodig?


  • Mottebelke
  • Registratie: Juni 2001
  • Laatst online: 13-08 16:52
Ja, dat is zo. Maar ik wil wel dat de gebruiker gewoon mm-dd-yyyy in moet vullen. Bestaat er een makkelijke manier om dat te converteren naar het ISO formaat?

Verwijderd

Wellicht niet helemaal wat je zoekt, maar om dergelijke problemen te voorkomen (zeker als je dezelfde scripts op meerdere servers hebt draaien), sla ik datum en tijd gegevens doorgaans op als string. Je maakt een 'datum naar string' en 'string naar datum' functie en een veld waarin je de datum, afhankelijk van hoe precies je het wilt hebben, op slaat als yyyymmddhhnnss. Door je datum op die manier te noteren (grootste eenheid links) kun je er ook gewoon > en < SQL selecties op los laten.

  • Mottebelke
  • Registratie: Juni 2001
  • Laatst online: 13-08 16:52
Maar je slaat de datum dus op als een string (bv. varchar) in database, en converteert die naar een date als je hem uitleest?
Ik heb het idd liever met een datetime in de database.

  • whoami
  • Registratie: December 2000
  • Laatst online: 21-08 22:54
Verwijderd schreef op 26 July 2003 @ 16:03:
Wellicht niet helemaal wat je zoekt, maar om dergelijke problemen te voorkomen (zeker als je dezelfde scripts op meerdere servers hebt draaien), sla ik datum en tijd gegevens doorgaans op als string.
Ranzig.
Datetime velden zijn er nu eenmaal op datums op te slaan. Daarmee kan je rekenen, het DBMS zorgt ervoor dat je geen ongeldige datums kunt opslaan ed.

Zorg er gewoon voor -als het dbms je het toelaat- dat je parameters gebruikt, dan zal je geen problemen hebben om datums op te slaan.

https://fgheysels.github.io/


Verwijderd

Verwijderd schreef op 26 July 2003 @ 16:03:
Wellicht niet helemaal wat je zoekt, maar om dergelijke problemen te voorkomen (zeker als je dezelfde scripts op meerdere servers hebt draaien), sla ik datum en tijd gegevens doorgaans op als string. Je maakt een 'datum naar string' en 'string naar datum' functie en een veld waarin je de datum, afhankelijk van hoe precies je het wilt hebben, op slaat als yyyymmddhhnnss. Door je datum op die manier te noteren (grootste eenheid links) kun je er ook gewoon > en < SQL selecties op los laten.
wat is dit voor een onzin. je gaat een datum toch niet als string opslaan. als je dan eens wilt selecteren, op een maand of zo. wordt allemaal wel erg ingewikkeld zo.

  • Mottebelke
  • Registratie: Juni 2001
  • Laatst online: 13-08 16:52
Zeg whoami, wat bedoel je met parameters? Zoiets als een stored procedure ofzo?

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Verwijderd schreef op 26 July 2003 @ 16:09:
[...]


wat is dit voor een onzin. je gaat een datum toch niet als string opslaan. als je dan eens wilt selecteren, op een maand of zo. wordt allemaal wel erg ingewikkeld zo.
Mee eens!

Je kunt in een datetime veld ook gewoon de datum inserten als "yyyymmddhhnnss" of "yyyymmdd hh:nn:ss", dit is gewoon ISO formaat en er is zat over te vinden op het web, in de handleiding en hier @GoT....

dus...
SQL:
1
Insert into MyTabel (myDate) values ('20030726 16:09:00')


levert gewoon 26 juli 2003, 16:09:00 op in je db en dan mag je "kolom" myDate dus gewoon van het type datetime zijn.

...quote uit helpfile:
Applications using other APIs, or Transact-SQL scripts, stored procedures, and triggers, should use the unseparated numeric strings (for example, yyyymmdd as 19980924).
en dit is wat google geeft....

Meestal gebruik ik (in ASP) een functie Date2SQL:
ASP:
1
2
3
Function Date2SQL(dtWhen)
  Date2SQL = Year(dtWhen) & Right("0" & Month(dtWhen),2) & Right("0" & Day(dtWhen),2) & " " & Right("0" & Hour(dtWhen),2) & ":" & Right("0" & Minute(dtWhen),2)
End Function

of iets dergelijks. Die roep je dan als volgt aan:
ASP:
1
2
strMyQuery = "Insert into MyTabel (myDate) values ('" & Date2SQL(Now) & "')"
oConn.Execute strMyQuery


Zie maar wat je er mee doet.

[ Voor 72% gewijzigd door RobIII op 26-07-2003 16:30 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


  • whoami
  • Registratie: December 2000
  • Laatst online: 21-08 22:54
Mottebelke schreef op 26 July 2003 @ 16:14:
Zeg whoami, wat bedoel je met parameters? Zoiets als een stored procedure ofzo?
Niet noodzakelijk met een stored procedure:

C#, SQL Server:
code:
1
2
3
4
5
6
7
SqlCommand1.CommandText = "INSERT INTO tabel (veld1, veld2) VALUES (@p1, @p2);

...

SqlCommand1.Parameters["@p1"].Value = eenDatum;
SqlCommand1.Parameters["@p2"].Value = eenVeld;
SqlCommand1.ExecuteNonQuery();

https://fgheysels.github.io/


  • Mottebelke
  • Registratie: Juni 2001
  • Laatst online: 13-08 16:52
Ik ben er al uit.
Ik heb nu gewoon de Session.LCID veranderd en nu werkt alles zoals het moet werken.

Bedankt voor jullie medewerking!

Verwijderd

ik heb 1 functie die ik overal include en deze zet iedere mogelijke datum om naar een datum die in SQL statements gebruikt kan worden. Ongeacht van de LCID die je op dat moment ingesteld hebt.

Verwijderd

En wat is '03/07/2003' dan? 3 juli of 7 maart?

  • TweakersOnly
  • Registratie: September 2000
  • Laatst online: 17:27
Ik hanteer altijd de onderstaande oplossing, die werkt voor zowel de Nederlandse als de Engelse datumnotatie:

Voordat ik een formulier aan de gebruiker laat zien, controleer ik eerst welk datumformaat op de server wordt gehanteerd.

ASP:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<%
FUNCTION getDatumformaat ()
    dim datum, maand, dag, posmaand, posdag
    datum = Date
    maand = Month(datum) & ""
    dag = Day(datum) & ""
    
    IF (maand = dag) THEN
        datum = date-1
        maand = Month(datum) & ""
        dag = Day(datum) & ""
    END IF

    posmaand = instr(1,datum,maand)
    posdag = instr(1,datum,dag)
    IF (posdag > posmaand) THEN
        getDatumformaat = "MM/DD/YYYY"
    ELSE
        getDatumformaat = "DD/MM/YYYY"
    END IF  
END FUNCTION


Als je de output van de functie op het formulier laat zien, weet de gebruiker altijd in welk formaat hij de gegevens moet invoeren.

Het datumformaat in Access kan je het beste op Engels laten staan. Bij de Engelse datumnotatie zal de webserver de ingelezen datums altijd omzetten naar de op de server geldende datumnotatie.

Voordeel van bovenstaande wijze is dat de datuminput gelijk is aan de output, onafhankelijk welk datumnotatie op de webserver wordt gehanteerd.
Pagina: 1