---

Jeg vil gerne lægge data ind via en form og det fungerer fint
hvisdato-feltet i AccessXP er et tekstfelt. Dato feltet i formen er
defineret som txt og beskedfeltet defneret som txtarea
Men sættes accessfeltet som dato/tid felt får jeg fejlen

"Der er en syntaksfejl i datoen i forespørgselsudtrykket "#30.10.2004#"."




min SQL er således ud i en response.write

Insert into Tbl_bog (dato,besked) values (#30.10.2004#, 'min tekst')

Jeg har også forsøgt at bruge forskellige afgrænsinger ', #. " men uden
held
Tænker på om jeg skal omdanne Request.Form("dato") til en datovariabel på
en eller anden måde i retning af: DatoVar = date(Request.Form("dato"))

What to do ?

---

Finn wrote in dk.edb.internet.webdesign.serverside.asp:
> Jeg vil gerne lægge data ind via en form og det fungerer fint
> hvisdato-feltet i AccessXP er et tekstfelt. Dato feltet i formen er
> defineret som txt og beskedfeltet defneret som txtarea
> Men sættes accessfeltet som dato/tid felt får jeg fejlen
>
> "Der er en syntaksfejl i datoen i forespørgselsudtrykket "#30.10.2004#"."
>
>
>
>
> min SQL er således ud i en response.write
>
> Insert into Tbl_bog (dato,besked) values (#30.10.2004#, 'min tekst')
>
> Jeg har også forsøgt at bruge forskellige afgrænsinger ', #. " men uden
> held
> Tænker på om jeg skal omdanne Request.Form("dato") til en datovariabel på
> en eller anden måde i retning af: DatoVar = date(Request.Form("dato"))
>
> What to do ?
>
>

Hej Finn.

Når man skal oprette en / ændre en dato i en access database er det
forskælligt fra normalt asp. I asp skal man skrive #01-01-2004# for den 1.
januar 2004. Når man skal indsætte det i en database skal det se sådan ud:
%01-01-2004%. Bemærk: at # er ændret til % og at dette er det eneste som er
ændret.

din sql streng er derfor som følger:

Insert into Tbl_bog (dato,besked) values (%30.10.2004%, 'min tekst')


Venlig hilsen Christian.

--
Vil du lære at kode HTML, XHTML, CSS, SSI, ASP eller ASP.NET?
- Pædagogiske tutorials på dansk
- Kom godt i gang med koderne
KLIK HER! => http://www.html.dk/tutorials

---

"Christian" <msn@ckweb.dk> skrev i en meddelelse
news:4184d260$0$33735$14726298@news.sunsite.dk...
> Når man skal oprette en / ændre en dato i en access database er det
> forskælligt fra normalt asp. I asp skal man skrive #01-01-2004# for den 1.
> januar 2004. Når man skal indsætte det i en database skal det se sådan ud:
> %01-01-2004%. Bemærk: at # er ændret til % og at dette er det eneste som
er
> ændret.
>
> din sql streng er derfor som følger:
>
> Insert into Tbl_bog (dato,besked) values (%30.10.2004%, 'min tekst')


Har prøvet med denne:
Insert into Tbl_bog (dato,besked) values (%30.10.2004%, 'tekst')
men får stadig fejlen: Der er en syntaksfejl i forespørgselsudtrykket
"%30.10.2004%".

---

Finn skrev:

> Insert into Tbl_bog (dato,besked) values (%30.10.2004%,
> 'tekst') men får stadig fejlen: Der er en syntaksfejl i
> forespørgselsudtrykket
> "%30.10.2004%".

Jeg har aldrig set % brugt ved datoangivelser før. Jeg vil tro at
du kan indsætte med:

'10/30/2004' - men jeg vil foreslå dig at sikre formatet ved at
bruge dateserial:

DateSerial(2004, 10, 30)

Altså:

Insert into Tbl_bog (dato,besked)
values (DateSerial(2004, 10, 30), 'tekst')

Dateserial tager tre parametre - år, måned og dag - og returnerer
den korrekte dato uanset format på server eller i database.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> skrev i en meddelelse
news:Xns9594A2D9C5F8jcdmfdk@gyrosmod.cybercity.dk...
>
> '10/30/2004' - men jeg vil foreslå dig at sikre formatet ved at
> bruge dateserial:
>
> DateSerial(2004, 10, 30)
>
> Altså:
>
> Insert into Tbl_bog (dato,besked)
> values (DateSerial(2004, 10, 30), 'tekst')


Takker. Jeg har brugt ' tidligere men får samme fejl. DateSerial funktionen
har jeg svært ved at bruge fordi jeg jo ikke skriver datoen ind i koden, men
henter den fra en form. Har prøvet at lave en varibel DatoVar
=DateSerial(reguest.form("dato")
men får forskellige fejl afhængig af paranteser og den slags.
Hvordan anvender jeg den sammen med data fra min form ?

---

Finn skrev:

> Takker. Jeg har brugt ' tidligere men får samme fejl.

Hvad brugte du som datoadskiller (altså '30.10.2004', '30-10-2004',
'30/10/2004' etc.?)

Og brugte du rækkefølgen mm-dd-yyyy eller dd-mm-yyyy?


> DateSerial funktionen har jeg svært ved at bruge fordi jeg jo ikke
> skriver datoen ind i koden, men henter den fra en form.

Det gør ikke noget - så skal du bare finde en måde at få de tre datodele
adskilt på. Hvis du bruger tre felter i formen til datoen, er det
særdeles let. Ellers kan det gøres ved hjælp af split-funktionen (se
lidt tilbage i gruppen, jeg mener der har været et eksempel oppe for
nylig).


> Har prøvet at lave en varibel DatoVar =DateSerial(reguest.form("dato")

Den går ikke - som nævnt tidligere skal DateSerial have tre argumenter -
her giver du den kun et.

--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Prøvet med flg.:

datovar= Request.Form("UsDato")
dd = left(datovar,2) ' Denne del er ikke sikker !!!!
mm = mid(datovar,4,2)
aa = right(datovar,4)


strSQL = "INSERT INTO Tbl_dato (datoFelt,besked) VALUES (DateSerial('" & dd
& "/ " & mm & "/ " & aa & "'))"
strSQL = strSQL & "'" & Request.Form("besked") & "')"
Set rs = Conn.Execute(strSQL)


Fejlen:
Antallet af forespørgselsværdier og destinationsfelter er ikke det samme.

POST Data:
UsDato=+1.11.2004&Besked=tekst

Hvor pokker henter den Usdato fra i sin SQL . Fejlen relaterer så til at jeg
sender mere data end jeg selv tror

SQL ser sådan ud i en response.write INSERT INTO Tbl_dato (datoFelt,besked)
VALUES (DateSerial(' 1/ 11/ 2004'))'tekst')

Hvilket matcher det der står i min request.form

---

Finn skrev:

> datovar= Request.Form("UsDato")

Hvordan ser datovar ud her? (udskriv med Response.write datovar)

> dd = left(datovar,2) ' Denne del er ikke sikker !!!!
> mm = mid(datovar,4,2)
> aa = right(datovar,4)

Hvad får du i hhv. dd, mm og åå? (igen, udskriv med response.write)


> strSQL = "INSERT INTO Tbl_dato (datoFelt,besked) VALUES (DateSerial('" & dd
> & "/ " & mm & "/ " & aa & "'))"

Her giver du (forudsat at din datosplitning virker korrekt) følgende
værdi til dateserial: 'dd/mm/yyyy' (fx '30/10/2004'). Det er forkert.
Dateserial skal som nævnt før have tre argumenter - og de tre argumenter
er tal og skal derfor ikke pakkes ind i anførselstegn.

Hvis dd, mm og aa findes korrekt, kan du skrive:

strSQL = "INSERT .... DateSerial(" & aa & ", " & mm & ", " & dd & ").."


> SQL ser sådan ud i en response.write INSERT INTO Tbl_dato (datoFelt,besked)
> VALUES (DateSerial(' 1/ 11/ 2004'))'tekst')

Den fejlmeddelelse du får kommer på grund af misforhold i parenteserne -
du har en lukkeparentes for meget efter DateSerial. Men argumentet til
Dateserial er - som nævnt tidligere i indlægget - også forkert.

--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> skrev i en meddelelse
news:rm2pmuuoxbsg.dlg@jcdmfdk.invalid...

> Hvordan ser datovar ud her? (udskriv med Response.write datovar)

Fuldstændig korrekt udseende

> > dd = left(datovar,2) ' Denne del er ikke sikker !!!!
> > mm = mid(datovar,4,2)
> > aa = right(datovar,4)
>
> Hvad får du i hhv. dd, mm og åå? (igen, udskriv med response.write)

formdata= 02.11.2004
dd 02

mm 11

aa 2004

Så det virker fint nok, men mangler sikkerhed hvis formatet ikke er
dd.mm.aaaa men der skrives d.m.aaaaa, så det skal jeg finde en bedre
løsning til


Min sql er sådan ud:

strSQL = "INSERT INTO Tbl_dato (datoFelt,besked) VALUES (DateSerial(" & aa &
"," & mm & "," & dd & ")"
strSQL = strSQL & "'" & Request.Form("besked") & "')"

og i response.write:
INSERT INTO Tbl_dato (datoFelt,besked) VALUES (DateSerial(2004,11,
02)'tekst')

men jeg får fejlen: Der er en syntaksfejl, fordi der mangler en operator. i
forespørgselsudtrykket "DateSerial(2004.11. 02)'tekst'".



Forresten.....tak for din udviste tålmodighed. Dejligt at opleve

mvh Finn

---

"Finn" <Finn@nomail.dk> skrev i en meddelelse
news:cm8knm$2g16$1@news.cybercity.dk...
>
> men jeg får fejlen: Der er en syntaksfejl, fordi der mangler en operator.
i
> forespørgselsudtrykket "DateSerial(2004.11. 02)'tekst'".

Jeg fandt den manglende operator (adskillelse mellem dato og teksten)
Tilbage står nu at sikre at jeg altid får splittet datostrengen ad i korrekt
format.
Gode ideer efterlyses, men jeg tænker at man må kunne validere den inden man
submitter den

---

Finn skrev:

> Tilbage står nu at sikre at jeg altid får splittet
> datostrengen ad i korrekt format.

Kig på funktionen Split. Den tager en streng som input og deler den
op i et array. Det gør at man kan splitte en dato korrekt uanset om
der står "2.5.2004", "20.3.2004", "2.10.2004" eller "02.03.2004"
(skilletegnet skal dog være det samme).

> Gode ideer efterlyses, men jeg tænker at man må kunne validere
> den inden man submitter den

Validering på klientsiden er en god ide, men det er kun et
supplement til validering på serversiden. Serversidevalidering er
din og brugerens garanti for at applikationen ikke fejler.

Klientsidevalidering er en hjælp til brugeren (og inddirekte til
dig) fordi det går hurtigere end serversidevalidering og man kan i
højere grad give hjælp til valideringen (fx ved at placere markøren
i det felt der skal rettes, eller ved simpelt hen at rette mindre
fejl automatisk). I forhold til datoer, kan man fx lave
javascriptvalidering der sørger for at ændre skilletegn samt ændrer
et tocifret årstal til et fircifret.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> skrev i en meddelelse
news:Xns9595E45A13A3jcdmfdk@gyrosmod.cybercity.dk...

> Kig på funktionen Split. Den tager en streng som input og deler den
> op i et array. Det gør at man kan splitte en dato korrekt uanset om
> der står "2.5.2004", "20.3.2004", "2.10.2004" eller "02.03.2004"
> (skilletegnet skal dog være det samme).

jeg kender ikke split funktionen og det jeg kan se på nettet forstod jeg
ikke helt sørgeligt men sandt.
Har du et godt eksempel jeg kan lære det ud fra ville jeg være taknemmelig.

mvh Finn

---

"Finn" <Finn@nomail.dk> skrev i en meddelelse
news:cmbblg$20aa$1@news.cybercity.dk...
>
> jeg kender ikke split funktionen og det jeg kan se på nettet forstod jeg
> ikke helt sørgeligt men sandt.
> Har du et godt eksempel jeg kan lære det ud fra ville jeg være
taknemmelig.
>
> mvh Finn


Dette virker så vidt jeg kan teste. Dog er der ingen check for en
korrekt/valid dato, men den splitter og de lægges korrekt i DB

dim a
a=Split(request.form("Usdato"),".")
dd = (a(0))
mm = (a(1))
aa = right(request.form("Usdato"),4)


response.write "dag " & dd &"<p>"
response.write "måned " & mm &"<p>"
response.write "År " & aa &"<p>"

---

Finn skrev:

> Dette virker så vidt jeg kan teste. Dog er der ingen check for en
> korrekt/valid dato, men den splitter og de lægges korrekt i DB

Det er en udmærket måde du har brugt split på. Hvis man vil validere
lidt undervejs, kan man fx tilføje følgende:

> dim a
> a=Split(request.form("Usdato"),".")

' Tjek hvor mange datodele som split returnerer
' (alt andet end 3 er en fejl)

If Ubound(a) <> 2 Then
' Håndter fejlen
Else
' Fortsæt

> dd = (a(0))
> mm = (a(1))
> aa = right(request.form("Usdato"),4)

Du kan også skrive:

aa = a(2)

' Tjek om datodelene er numeriske:

If NOT (isnumeric(dd) AND isnumeric(mm) AND isnumeric(aa)) Then
' Håndter fejlen
Else
' Fortsæt
' Tjek om datodelene er i orden (ikke 100%)
If NOT (CInt(dd) <= 31 AND CInt(mm) <= 12 AND CInt(aa) > 1900) Then
   ' Håndter fejlen
Else
   ' Fortsæt
End IF
End IF
End IF


En anden tilgang til fejlhåndtering er at bruge asp's eget fejlobjekt.
Man skal skrive On Error Resume Next hvis man selv vil styre
fejlhåndteringen. Herefter kan man tjekke værdien af Err.Number - hvis
den er større end nul, har man en fejl.

--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> skrev i en meddelelse
news:1wxmhz2y1w120$.dlg@jcdmfdk.invalid...
> Det er en udmærket måde du har brugt split på. Hvis man vil validere
>
> En anden tilgang til fejlhåndtering er at bruge asp's eget fejlobjekt.
> Man skal skrive On Error Resume Next hvis man selv vil styre
> fejlhåndteringen. Herefter kan man tjekke værdien af Err.Number - hvis
> den er større end nul, har man en fejl.

God ide. Tak for hjælp og inspiration

mvh Finn

---

Finn wrote:
> Jeg vil gerne lægge data ind via en form og det fungerer fint
> hvisdato-feltet i AccessXP er et tekstfelt. Dato feltet i formen er
> defineret som txt og beskedfeltet defneret som txtarea
> Men sættes accessfeltet som dato/tid felt får jeg fejlen
>
> "Der er en syntaksfejl i datoen i forespørgselsudtrykket "#30.10.2004#"."
>
> min SQL er således ud i en response.write
>
> Insert into Tbl_bog (dato,besked) values (#30.10.2004#, 'min tekst')
>
> Jeg har også forsøgt at bruge forskellige afgrænsinger ', #. " men uden
> held
> Tænker på om jeg skal omdanne Request.Form("dato") til en datovariabel på
> en eller anden måde i retning af: DatoVar = date(Request.Form("dato"))
>
> What to do ?

Bruken av datoer i databaser er en av de ting som virkelig kan skape
problemer. Etter mitt syn har du allerede funnet løsningen på problemet
når du skriver at alt fungerer fint når du lagrer datoene i et
tekstfelt. Hvis du alltid lagrer en dato verdi som tekst, ikke dato, og
dessuten alltid formaterer denne verdien på den samme måten (se under),
så bør du ha god kontroll på hva som lagres i databasen og, ikke minst,
hvordan denne verdi skal vises for en bruker. Se på denne lille funksjonen:

Function dbDate(dt)
   dbDate = Year(dt) & Right("0" & Month(dt), 2) &_
   Right("0" & Day(dt), 2) & " " & FormatDateTime(dt, 3)
End Function

Funksjonen vil produsere denne string verdien: 20041031 16:28:59
Når du så skal hente denne verdien ut fra databasen vil du alltid vite
hva som er måned, år osv. Problemer med ulike settinger i Access, SQL
Server, IIS, Windows samt brukere fra land med ulike datoformater vil da
kunne unngås.

Funksjonen over er hentet fra denne link, som også diskuterer
datoproblemene inngående.
http://www.aspfaq.com/show.asp?id=2260

terje

---

"terje" <nidaros2001@hotmail.com> skrev i en meddelelse
news:2ukeohF29v2thU1@uni-berlin.de...
> Hvis du alltid lagrer en dato verdi som tekst, ikke dato, og
> dessuten alltid formaterer denne verdien på den samme måten (se under),
> så bør du ha god kontroll på hva som lagres i databasen og, ikke minst,
> hvordan denne verdi skal vises for en bruker. Se på denne lille
funksjonen:


takker, men problemet med det er så, at den ikke sorterer korrekt. Korrekt
forstået på den måde at den sorteres som tekst og ikke dato hvilket jo giver
hvert sig udslag

---

Finn wrote:
> takker, men problemet med det er så, at den ikke sorterer korrekt. Korrekt
> forstået på den måde at den sorteres som tekst og ikke dato hvilket jo giver
> hvert sig udslag

Det er riktig at sortering på dato er problematisk når datoen er lagret
som en tekst streng. Hvis det er nødvendig med slik sortering kan en
løsning være å lagre år, måned og dag i forskjellige databasefelt,
kanskje konvertert til tall verdier. Men det er klart at dette krever en
del koding. Som alltid blir det en avveining av fordeler og ulemper sett
i lys av hva applikasjonen skal gjøre og hvilke brukere den har.

terje

---

terje skrev:

> Bruken av datoer i databaser er en av de ting som virkelig kan
> skape problemer.

Så langt er vi enige.


> Hvis du alltid lagrer en dato verdi som tekst, ikke dato, og
> dessuten alltid formaterer denne verdien på den samme måten
> (se under), så bør du ha god kontroll på hva som lagres i
> databasen og, ikke minst, hvordan denne verdi skal vises for
> en bruker.

- men jeg er ikke enig i at det er en god ide at bruge tekst-format
til datoer for at undgå problemer. Man kan måske løse nogle
problemer, men man får mindst lige så mange nye - fx sortering.


> Function dbDate(dt)
> dbDate = Year(dt) & Right("0" & Month(dt), 2) &_
> Right("0" & Day(dt), 2) & " " & FormatDateTime(dt, 3)
> End Function

Den funktion her er efter min mening skruet helt galt sammen.
Problemet er at du bruger datofunktioner (year, month, day) til at
trække de enkelte dele af datoen ud - og hvis din "dt"-dato bliver
opfattet forkert, så vil din funktion også levere en forkert dato.

Funktionen virker fint når den får en datotype ind (fx Now()), men
den er afhængig af locale hvis input er en tekststreng (fx fra en
form) der først skal konverteres til en dato (for så igen at blive
konverteret til tekst).

Problemet med modtagerens (typisk en database) mulige fejllæsning
af en dato, kan løses med en datofunktion - fx DateSerial i Access
(<http://asp-faq.dk/article/?id=98>)

Problemet med at en afsendt dato i tekstformat kan fejlopfattes,
kan enten løses ved at lægge dag, måned og år i separate felter i
formen, eller ved at bruge tekstfunktioner (left/mid/right) i
stedet for datofunktioner når man skal aflæse/afkode en tekstdato.



> Funksjonen over er hentet fra denne link, som også diskuterer
> datoproblemene inngående.
> http://www.aspfaq.com/show.asp?id=2260

Artiklen gennemgår LCID ganske grundigt, men den nævner ikke
modtagelsen af datoer fra formularer med et ord - og som nævnt
tager den funktion artiklen angiver som løsning heller ikke højde
for dette.
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Jens Gyldenkærne Clausen wrote:
> - men jeg er ikke enig i at det er en god ide at bruge tekst-format
> til datoer for at undgå problemer. Man kan måske løse nogle
> problemer, men man får mindst lige så mange nye - fx sortering.

Enig. Dette er hovedsvakheten med å lagre en dato som tekst, ellers
hadde det vært genialt
Man kan altså lagre år/måned/dag/tid i separate felt som tall, og dette
vil løse en del av sorteringsproblemene. F. eks. kan man da sammenligne
to verdier med < > operatorene, men man vet ikke uten videre om verdien
11 er større enn 10 uten at man samtidig sammenligner verdiene i måned
og år feltene. Dette blir uansett ingen god løsning, så jeg er i grunnen
enig med deg i at konvertering av en dato til tekst ikke er veien å gå.

>>Function dbDate(dt)
>> dbDate = Year(dt) & Right("0" & Month(dt), 2) &_
>> Right("0" & Day(dt), 2) & " " & FormatDateTime(dt, 3)
>>End Function
>
>
> Den funktion her er efter min mening skruet helt galt sammen.
> Problemet er at du bruger datofunktioner (year, month, day) til at
> trække de enkelte dele af datoen ud - og hvis din "dt"-dato bliver
> opfattet forkert, så vil din funktion også levere en forkert dato.
>
> Funktionen virker fint når den får en datotype ind (fx Now()), men
> den er afhængig af locale hvis input er en tekststreng (fx fra en
> form) der først skal konverteres til en dato (for så igen at blive
> konverteret til tekst).

Det er mulig at jeg misforstår deg, men den samme locale setting som
styrer year, month, day funksjonene vil vel også styre konvertering av
en dato i tekst form, slik at month blir month uansett? Hvis den
tekststreng du snakker om her ikke kan brukes i funksjonen over, så kan
den nok heller ikke konverteres til "UNIX tid" eller overleve DateSerial
i en SQL streng.


> Problemet med modtagerens (typisk en database) mulige fejllæsning
> af en dato, kan løses med en datofunktion - fx DateSerial i Access
> (<http://asp-faq.dk/article/?id=98>)

Vel, forhåpentligvis. Det forutsetter jo at Access behandler dato
verdiene slik vbscript funksjonen DateSerial gjør, f. eks. ved
sammenligning av to datoer. Vil Access alltid gjøre det? På alle
maskiner, i alle sammenhenger?

> Problemet med at en afsendt dato i tekstformat kan fejlopfattes,
> kan enten løses ved at lægge dag, måned og år i separate felter i
> formen, eller ved at bruge tekstfunktioner (left/mid/right) i
> stedet for datofunktioner når man skal aflæse/afkode en tekstdato.

Jeg vil heller si: "Problemet med at en afsendt dato i <any> format kan
fejlopfattes.." kan løses ved at man selv tar kontroll med hvor de ulike
delene av en dato tar veien. Dette er hovedsaken. Når dette er i orden
så kan man vise datoverdier til en bruker slik man ønsker, samt
kalkulere datoer mot hverandre etter hjertets lyst.

Min konklusjon blir vel at det ikke finnes noen perfekt løsning på
dette. Jeg er enig i at løsningen som skisseres i din link er langt
bedre egnet enn å konvertere datoer til tekst, som jeg startet med.
Iallefall om man har behov for å gjøre dato kalkulasjoner. Så jeg går
også for den, selv om jeg vil ha i bakhodet at databasen og web serveren
kanskje ikke alltid er enig med meg i hvordan to datoer skal
sammenlignes

terje

---

terje wrote:
Jeg har sovet fryktelig dårlig i natt så hvorfor ikke svare meg selv?
Mens jeg har rullet fram og tilbake i sengen så har jeg gjort mitt
standpunkt klarere. Glem datoer lagret som text i databaser. Det er et
feilspor. Men tall derimot, og numeriske database felt, er en forbannet
god løsning.

> Man kan altså lagre år/måned/dag/tid i separate felt som tall, og dette
> vil løse en del av sorteringsproblemene. F. eks. kan man da sammenligne
> to verdier med < > operatorene, men man vet ikke uten videre om verdien
> 11 er større enn 10 uten at man samtidig sammenligner verdiene i måned
> og år feltene.

Helt riktig, terje. Her treffer du spikeren på hodet.
Dette blir en god løsning dersom jeg følger resonnementet helt ut. Hvis
jeg har en datoverdi som ser slik ut: 20041101 så er denne helt perfekt
til å sammenligne datoer. Det bør også skje hurtig siden sammenligning
av tall skjer uten konvertering av datatyper og unødvendig intern
prosessering i Access.

Hva om jeg ønsker å hente ut alle datoer fra år 2003, eller alle datoer
større enn 21 Mai i 2004? Løsningen er å opprette flere datofelt. Ja,
jeg lager et eget felt for år, måned og dag. Og for å være litt fancy så
lager jeg også egne felt for time, minutt og sekund. Med disse database
feltene har jeg full kontroll over alle dato kalkulasjoner og trenger
ikke lenger bekymre meg for interne settinger i Access, IIS, SQL SERVER,
Windows eller vbscript funksjonene. Eneste minus er at dette vil øke
størrelsen på databasen, men det er til å leve med.

Dette er alt jeg trenger:

Function MakeDatePart(t, i)
If Len(t) > i Or Not IsNumeric(t) Then MakeDatePart = 0: Exit Function
MakeDatePart = CLng(t)
End Function

Function Pad(d)
If Len(d) = 1 Then d = ("0" & d)
Pad = CStr(d)
End Function

Response.Write MakeDatePart(CStr(Year(Now) & Pad(Month(Now)) &
Pad(Day(Now))), 8) & "<br />"
Response.Write MakeDatePart("2004", 4) & "<br/>"
Response.Write MakeDatePart(Year(Date), 4) & "<br/>"
Response.Write MakeDatePart(Month(Now), 2) & "<br/>"
Response.Write MakeDatePart("01", 2) & "<br/>"
Response.Write MakeDatePart(Day(Now), 2) & "<br />"
Response.Write MakeDatePart(Hour(Now), 2) & "<br/>"
Response.Write MakeDatePart(Minute(Now), 2) & "<br/>"
Response.Write MakeDatePart(Second(Now), 2) & "<br/>"

Dersom datoene kommer i form av tekst variabler fra et skjema, som er
denne trådens oppgave, så ser jeg intet problem med det. Man bruker et
text felt for hver dato verdi. Enhver input verdi må som vanlig sjekkes
for riktig syntaks. Først gjerne med javascript på klienten, så med ASP
på serveren. Det er ikke nødvendig å først konvertere til Date
variabler, og deretter til tall.

Jeg har også kommet til den konklusjon at UNIXTIME-konseptet er meget
interessant (se innlegg av Troels Jensen). Jeg forstår strengt tatt ikke
hvorfor det tok så lang tid for meg å forstå dette. Kanskje likte jeg
ikke iden om å definere et startpunkt den 1.1.1970. Nå ser jeg denne
metoden som et godt alternativ, men å kun benytte seg av sekunder føler
jeg er en begrensning. Hvorfor ikke lage f. eks. en UNIXDag verdi i
tillegg og definere startpunktet for denne lik 01.01.1900? Noe etter
disse linjer:

Function UNIXDag()
UNIXDag = DateSerial(1900, 1, 1)
End Function

Function Time2UNIXDag(dTime)
Time2UNIXDag = DateDiff("d", UNIXDag, dTime)
End Function

Alt i alt synes jeg likevel at tall løsningen er den beste.

terje

---

terje wrote in dk.edb.internet.webdesign.serverside.asp:

> Hvorfor ikke lage f. eks. en UNIXDag verdi i
> tillegg og definere startpunktet for denne lik 01.01.1900? Noe etter
> disse linjer:
>
> Function UNIXDag()
> UNIXDag = DateSerial(1900, 1, 1)
> End Function
>
> Function Time2UNIXDag(dTime)
> Time2UNIXDag = DateDiff("d", UNIXDag, dTime)
> End Function

Jeg kan bare godt lide ideen med, at man lagrer antal sekunder. Så kan
man lave om på fremvisning af data i databasen så meget, man vil. Hvis
man kun lagrer datoen og senere vil udvide f.eks. gæstebogen med
klokkeslet, så er løbet kørt.

--
Mvh.

Troels Jensen
http://www.troelsweb.dk

---

Tak til jer begge to

---

Finn wrote in dk.edb.internet.webdesign.serverside.asp:
> Jeg vil gerne lægge data ind via en form og det fungerer fint
> hvisdato-feltet i AccessXP er et tekstfelt. Dato feltet i formen er
> defineret som txt og beskedfeltet defneret som txtarea
> Men sættes accessfeltet som dato/tid felt får jeg fejlen
>
> "Der er en syntaksfejl i datoen i forespørgselsudtrykket "#30.10.2004#"."

Kender du til tidsangivelsen 'sekunder fra 1970'? Det lyder bøvlet, men
efter min mening er det den letteste måde at indsætte datoer i databaser
på. Og så er det let at sortere.

<http://activedeveloper.dk/artikler/default.asp?articleid=322>

--
Mvh.

Troels Jensen
http://www.troelsweb.dk

---

"Troels Jensen" <tjREMOVE@THIStroelsweb.dk> skrev i en meddelelse
news:MPG.1bef90bbd71042a09896bd@news.tele.dk...
> Kender du til tidsangivelsen 'sekunder fra 1970'? Det lyder bøvlet, men
> efter min mening er det den letteste måde at indsætte datoer i databaser
> på. Og så er det let at sortere.
>
> <http://activedeveloper.dk/artikler/default.asp?articleid=322>
>
nej det var ukendt for mig. Og ikke lige forståeligt, men tak for den
alligevel

---

Finn wrote in dk.edb.internet.webdesign.serverside.asp:

> nej det var ukendt for mig. Og ikke lige forståeligt, men tak for den
> alligevel

Det er såre enkelt: Inden datoen og klokkeslettet bliver smidt i
databasen, bliver den konverteret til sekunder efter 1970. Dette er et
mangecifret tal - til gengæld er det superlet at lagre som integer i
databasen.

Når du så skal bruge en dato, så konverterer du tilbage igen. Det smarte
er, at du så kan bruge alle mulige formater, du selv kan rette til.

Jeg er ikke (!) bare en lille smule erfaren asp-bruger, men det her har
hjulpet mig meget. Så jeg ville mene, at det er værd at bruge ti
minutter på.

--
Mvh.

Troels Jensen
http://www.troelsweb.dk

---

Troels Jensen wrote in dk.edb.internet.webdesign.serverside.asp:

> Når du så skal bruge en dato, så konverterer du tilbage igen. Det smarte
> er, at du så kan bruge alle mulige formater, du selv kan rette til.

Jeg kommer lige i tanke om, at der faktisk er nogle svagheder ved
metoden. For eksempel vil det kræve en del programmering at få formatet
konverteret til den rette ugedag...

--
Mvh.

Troels Jensen
http://www.troelsweb.dk

---

Troels Jensen wrote:
> Troels Jensen wrote in dk.edb.internet.webdesign.serverside.asp:
>
>
>>Når du så skal bruge en dato, så konverterer du tilbage igen. Det smarte
>>er, at du så kan bruge alle mulige formater, du selv kan rette til.
>
>
> Jeg kommer lige i tanke om, at der faktisk er nogle svagheder ved
> metoden. For eksempel vil det kræve en del programmering at få formatet
> konverteret til den rette ugedag...

Du skrev nettopp i forrige innlegg at du lagret dine sekunder som
integer i databasen. Er du sikker på dette? Datatypen integer kan bare
takle verdier fra –32,768 til 32,767. Hvis du derimot benytter datatypen
Currency så vil det fungere.

En oppsummering:


UNIXTIME Metoden:

Plus:
UNIXTime funksjonen returnerer en Date datatype som konverteres til
Currency og lagres i databasen også som datatypen Currency. Med disse
datatypene er det ingen fare for overflow error "uansett" hvor små eller
store datoer man benytter. Ingen problemer med dato og format settinger
man ikke har kontroll over.

Minus:
- Man må forholde seg til negative tall verdier når datoene er eldre enn
1970, 1, 1.
- Man kan ikke uten videre bruke spørringer som dette: SELECT * FROM
MyTable WHERE (Dato) = (18 Mai 2003). Da må man først definere en start
og sluttverdi for denne dagen, nemlig en verdi som tilsvarer klokka
24:00:00 den 17 Mai, samt klokka 24:00:00 den 18 Mai. Alle records som
ligger mellom disse er gyldige.

MyDay = "14"
MyMonth = "12"
MyYear = "1901"

MyDateValuesFromAForm = DateSerial(MyYear, MyMonth, MyDay)

Response.Write CCur(Time2UNIX(MyDateValuesFromAForm)) ' = -2147472000
Response.Write UNIX2Time("-2147472000") ' = 14.12.1901

Function UNIXTime()
UNIXTime = DateSerial(1970, 1, 1)
End Function
Function Time2UNIX(dTime)
Time2UNIX = DateDiff("s", UNIXTime, dTime)
End Function

Function UNIX2Time(nUNIX)
UNIX2Time =DateAdd("s", nUNIX, UNIXTime)
End Function


TALL Metoden:

Jeg konverterer string verdiene fra skjema til Currency og lagrer disse
i databasen der også Dato feltet defineres som Datatypen Currency.
Heller ikke her risikerer vi overflow problemer. Det ville vi fått med
Long eller Integer variabler.
Jeg er usikker på hvor mange dato/tid verdier det er praktisk å benytte,
men jeg tror jeg vil ha en Dato(20041101) og en Tid(231425). Jeg tror
jeg også vil lagre alle individuelle dato/tids verdier for seg, men
dette må testes.

Plus:
SELECT * FROM MyTable WHERE (Dato) = (18 Mai 2003) blir mye enklere:
SELECT * FROM MyTable WHERE (Dato) = (20030518). Ingen problemer med
dato og format settinger man ikke har kontroll over.

Minus:
Databasen vil øke i volum med mange data felt.

Dato = 20041224
Tid = 020959
Year = 2004
Sekund = 59
osv

terje

---

terje wrote in dk.edb.internet.webdesign.serverside.asp:

> Du skrev nettopp i forrige innlegg at du lagret dine sekunder som
> integer i databasen. Er du sikker på dette? Datatypen integer kan bare
> takle verdier fra ?32,768 til 32,767. Hvis du derimot benytter datatypen
> Currency så vil det fungere.

Jeg glemte at skrive, at jeg bruger MySQL. Jeg har lige tjekket, og jeg
bruger typen INT til mine tal. Men jeg ved ikke så meget om databaser -
jeg bruger dem bare

> Minus:
> - Man må forholde seg til negative tall verdier når datoene er eldre enn
> 1970, 1, 1.

Så må man jo bruge den franske revolution eller Jesu fødsel i stedet.

> - Man kan ikke uten videre bruke spørringer som dette: SELECT * FROM
> MyTable WHERE (Dato) = (18 Mai 2003). Da må man først definere en start
> og sluttverdi for denne dagen, nemlig en verdi som tilsvarer klokka
> 24:00:00 den 17 Mai, samt klokka 24:00:00 den 18 Mai. Alle records som
> ligger mellom disse er gyldige.

Det er rigtigt. Jeg arbejder ikke med at trække bestemte poster ud af
databasen, så mit forslag er overhovedet ikke så gennemtænkt, at det er
brugbart i alle situationer.


--
Mvh.

Troels Jensen
http://www.troelsweb.dk

---

"Troels Jensen" <tjREMOVE@THIStroelsweb.dk> skrev i en meddelelse
news:MPG.1bf0d7d974e86e5a9896c1@news.tele.dk...
> Troels Jensen wrote in dk.edb.internet.webdesign.serverside.asp:
>
> > Når du så skal bruge en dato, så konverterer du tilbage igen. Det smarte
> > er, at du så kan bruge alle mulige formater, du selv kan rette til.
>
> Jeg kommer lige i tanke om, at der faktisk er nogle svagheder ved
> metoden. For eksempel vil det kræve en del programmering at få formatet
> konverteret til den rette ugedag...
>

Jeg tror nok den største svaghed i det spørgsmål snarere er mig , men jeg
prøver at lege med det
Man bliver aldrig dummere.....men måske bare forvirret på et højere plan


mvh Finn