---

Jeg har følgende kode:

con.Execute "INSERT INTO Booking_Tmp (SpotID, AntalPrTime, Dato, Time)
" & _
"VALUES (" & fSpotID & ", " & rs("t0" & x) & ", " & myDate & ", " & x
& ")"

Et debug af linien viser:
INSERT INTO Booking_Tmp (SpotID, AntalPrTime, Dato, Time) VALUES (100,
1, 01-04-2002, 6)

Data ligger på SQL-server, og feltet er af typen DateTime.
Men når jeg kigger i tabellen får jeg datoen 06-07-1894

Jeg har prøvet med ...#" & myDate & "#...
, altså med havelåger. Men så får jeg en ugyldig sql-sætning.

Nogle idéer til hvad problemet kan være?

mvh
Morten Snedker

---

Morten Snedker <morten.nospam@dbconsult.dk> skrev:

> Data ligger på SQL-server, og feltet er af typen DateTime.
> Men når jeg kigger i tabellen får jeg datoen 06-07-1894

SQL's default-datoformat er vist nok YYYY-MM-DD - men hvis du vil
slippe for at komme i tvivl, kan du benytte CONVERT-funktionen.

*****
INSERT INTO tabelnavn (datofelt)
VALUES CONVERT(datetime, '01-04-2002', 105)
*****

Ovenstående virker med den normale "danske" angivelse dd-mm-yyyy.
Den sidste parameter angiver formatet - 104 er "tysk" - dvs.
dd.mm.yyyy og 103 er britisk/fransk: dd/mm/yyyy. Hvis du trækker
100 fra koderne får du de samme formater med tocifret årstal (dd-
mm-yy, dd.mm.yy og dd/mm/yy).


> Jeg har prøvet med ...#" & myDate & "#...

Virker kun i Access.


--
Jens Gyldenkærne Clausen
MF (medlem af FIDUSO - www.fiduso.dk)

---

On Wed, 24 Apr 2002 14:58:11 +0000 (UTC), "Jens Gyldenkærne Clausen"
<jc@dmf.dk> wrote:

>INSERT INTO tabelnavn (datofelt)
>VALUES CONVERT(datetime, '01-04-2002', 105)

Tak for hjælpen. Den endelige, funktionelle, løsning blev:

con.Execute "INSERT INTO Booking_Tmp (SpotID, AntalPrTime, Dato, Time)
" & _
"VALUES (" & fSpotID & ", " & rs("t0" & x) & ", CONVERT(DateTime, '" &
CStr(myDate) & "', 105), " & x & ")"

I øvrigt en lidt ærgelig løsning, da det er meningen at data valgfrit
kan ligge i Access-mdb, eller på en Sql-server.

/Snedker

---

Morten Snedker skrev:
> Tak for hjælpen. Den endelige, funktionelle, løsning blev:
....
> CStr(myDate) & "', 105), " & x & ")"
>
> I øvrigt en lidt ærgelig løsning, ...

....da den kun virker på computere hvor regional settings (mere
specifikt: datoformatet) er sat op på samme måde som det tilfældigvis
måtte være sat på på den computer, som du udvikler på!

Husk på at alle VB's konverteringsfunktioner, som starter med "C" alle
tager højde for de lande-specifikke indstillinger.
Dette kan undgås ved f.eks. at bruger Format-funktionen.

Eksempel:

....Format(myDate,"DD-MM-YYYY") & "'",...

-------
Tomas

---

Hej

Bryder lige ind...

Jeg har lært af erfaring at det med fordel kan anbefales at konvertere
datoen til en langt tal YYYYMMDD
På den måde vil det virke på alle systemer.

Johnny


"Tomas Christiansen" <toc@blikroer.removethis.dk> skrev i en meddelelse
news:aa6v7f$2mar$1@news.cybercity.dk...
> Morten Snedker skrev:
> > Tak for hjælpen. Den endelige, funktionelle, løsning blev:
> ...
> > CStr(myDate) & "', 105), " & x & ")"
> >
> > I øvrigt en lidt ærgelig løsning, ...
>
> ...da den kun virker på computere hvor regional settings (mere
> specifikt: datoformatet) er sat op på samme måde som det tilfældigvis
> måtte være sat på på den computer, som du udvikler på!
>
> Husk på at alle VB's konverteringsfunktioner, som starter med "C" alle
> tager højde for de lande-specifikke indstillinger.
> Dette kan undgås ved f.eks. at bruger Format-funktionen.
>
> Eksempel:
>
> ...Format(myDate,"DD-MM-YYYY") & "'",...
>
> -------
> Tomas
>

---

Johnny Emde Jensen skrev:
> Jeg har lært af erfaring at det med fordel kan anbefales at
konvertere
> datoen til en langt tal YYYYMMDD
> På den måde vil det virke på alle systemer.

Godt forslag.

Jeg har lige testet det mod en Oracle 8.1.7 server, og den accepterer
datoen, hvis den angives på det format, som du foreslår, men den skal
angives som en streng (dvs. med apostroffer omkring).

Insert into test_tabel (dato, tekst, tal)
values ('20020425', 'Dette er en tekst', 123);

-------
Tomas

---

Faktisk ret dårlig forslag. MS SQL / Access SQL har dato standard format
mm/dd/yyyy - uafhængig af instillinger. Skal du lave en sql i kode:
strSQL = "SELECT .... " & _
" WHERE datofelt = #" & format(minDato, "mm/dd/yyyy") & "#"

Brug altid mm/dd/yyyy format for dato, så virker det på alle systemer

BG

"Tomas Christiansen" <toc@blikroer.removethis.dk> wrote in message
news:aa9rnb$13ln$1@news.cybercity.dk...
> Johnny Emde Jensen skrev:
> > Jeg har lært af erfaring at det med fordel kan anbefales at
> konvertere
> > datoen til en langt tal YYYYMMDD
> > På den måde vil det virke på alle systemer.
>
> Godt forslag.
>
> Jeg har lige testet det mod en Oracle 8.1.7 server, og den accepterer
> datoen, hvis den angives på det format, som du foreslår, men den skal
> angives som en streng (dvs. med apostroffer omkring).
>
> Insert into test_tabel (dato, tekst, tal)
> values ('20020425', 'Dette er en tekst', 123);
>
> -------
> Tomas
>

---

Barney Gumble skrev:
> Faktisk ret dårlig forslag.

Hmm. Vil det sige at du mener at det ikke virker - modsat Johnny's
erfaringer og min test mod Oracle?

Jeg vil dog medgive at Access ikke vil være med på vognen med YYYYMMDD
eller 'YYYYMMDD'.

Access vil dog acceptere YYYY-MM-DD og 'YYYY-MM-DD'.
Oracle vil gerne acceptere 'YYYY-MM-DD'.
Hvad siger MS SQL server til disse to formater?


> Brug altid mm/dd/yyyy format for dato, så virker det på alle
systemer

*Alle* ? Det er vist en sandhed med modifikationer.
Oracle kender ikke til det format, som du foreslår.

-------
Tomas

---

I Oracle kan man specificere hvilken format dato kommer på - inkl.
mm/dd/yyyy. Dersom man bruger ADO, så er det best at benytte mm/dd/yyyy idet
MS (ADO/DAO) bruger det som standard (ufhængig af system datoformat eller DB
datoformat).
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vdbt7/html/
dvconenteringdatesingridsqlpanes.asp
Det er nemlig hele poeng med at bruge ADO - så man har standardiseret kald
mod DB. Læg mærke til at f.eks. Access bruger * som wildecard, men hvis man
skal søge via ADO så er det % på samme måde som i SQL eller Oracle. Med ADO
behøver man ikke at være specifik for given DB - næmmer at flytte fra den
ene DB til den anden uden at ændre kode (kun ConnectionString).

BG

"Tomas Christiansen" <toc@blikroer.removethis.dk> wrote in message
news:aaciev$1oi4$1@news.cybercity.dk...
> > Brug altid mm/dd/yyyy format for dato, så virker det på alle
> systemer
>
> *Alle* ? Det er vist en sandhed med modifikationer.
> Oracle kender ikke til det format, som du foreslår.
>
> -------
> Tomas
>

---

Jeg anbefaler også at man definerer tallet, som et langt heltal i databasen,
og så indsætter tallet som yyyymmdd, på den måde kan man også sortere. Den
eneste fejl, er at der ikke automatisk nliver checket for dato fejl, eks.
20021435, er jo også gyldig. Og format benytter også region varabler, f.eks
giver Format(4.67, "0.00") = "4,67", altså uden punktum. Derfor angiver jeg
også alle tal i databasen som heltal, opgivet i ører (10.95 kr= 1095 ører).

Mvh Rayman.

"Barney Gumble" <dadrinker.nospam@hotmail.com> wrote in message
news:aadp8o$30gc$1@news.cybercity.dk...
> I Oracle kan man specificere hvilken format dato kommer på - inkl.
> mm/dd/yyyy. Dersom man bruger ADO, så er det best at benytte mm/dd/yyyy
idet
> MS (ADO/DAO) bruger det som standard (ufhængig af system datoformat eller
DB
> datoformat).
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vdbt7/html/
> dvconenteringdatesingridsqlpanes.asp
> Det er nemlig hele poeng med at bruge ADO - så man har standardiseret kald
> mod DB. Læg mærke til at f.eks. Access bruger * som wildecard, men hvis
man
> skal søge via ADO så er det % på samme måde som i SQL eller Oracle. Med
ADO
> behøver man ikke at være specifik for given DB - næmmer at flytte fra den
> ene DB til den anden uden at ændre kode (kun ConnectionString).
>
> BG
>
> "Tomas Christiansen" <toc@blikroer.removethis.dk> wrote in message
> news:aaciev$1oi4$1@news.cybercity.dk...
> > > Brug altid mm/dd/yyyy format for dato, så virker det på alle
> > systemer
> >
> > *Alle* ? Det er vist en sandhed med modifikationer.
> > Oracle kender ikke til det format, som du foreslår.
> >
> > -------
> > Tomas
> >
>
>

---

Barney Gumble skrev:
> I Oracle kan man specificere hvilken format dato kommer på

Jo, tak. Jeg ved det, men min del af diskussionen udsprang af Johnny
Emde Jensens kommentar:

> Jeg har lært af erfaring at det med fordel kan anbefales at
konvertere
> datoen til en langt tal YYYYMMDD
> På den måde vil det virke på alle systemer.

som gik på en metode, som skulle kunne bruges på alle databaser. Hvert
system har naturligvis altid deres egen specifikke måde at gøre det
på, men kunne man finde en fællesnævner, ville det jo ikke være så
galt.

> Dersom man bruger ADO, så er det best at benytte mm/dd/yyyy idet
> MS (ADO/DAO) bruger det som standard (ufhængig af system datoformat
eller DB
> datoformat).

Det VILLE jo have været rart, hvis det er sandt - men det er det
desværre bare ikke...

Det indlæg, som startede det hele, gik jo på en .Execute:

> con.Execute "INSERT INTO Booking_Tmp (SpotID, AntalPrTime, Dato,
Time) " & _
> "VALUES (" & fSpotID & ", " & rs("t0" & x) & ", " & myDate & ", " &
x & ")"

Her er man jo helt og holdent overladt til mål-databasens opfattelse
af de værdier, som skal indsættes i tabellen. Med andre ord bliver
hele SQL-strengen (uden at ADO forsøger at "gøre noget ved"
indholdet") sendt direkte til databasen.

Mon det er mon fordi du tænker på, at man kan opdatere et felt af type
Date i en database-tabel, f.eks. på denne måde:

rs.AddNew
rs.Field("DatoFelt").Value = #04/28/2002#
rs.Update

Så vil jeg lige for en ordens skyld gøre opmærksom på at ADO i og for
sig ikke har noget med formatet #MM/DD/YYYY# at gøre - det er en ren
VB-ting. ADO skjuler dog mål-databasens faktiske dato-format, og
forestår omsætningen mellem VB's Date-type og databasens Date-type.

Jeg mener derfor ikke at man kan derfor ikke sige at ADO bruger
formatet MM/DD/YYYY. ADO ved intet om hvilket datoformat
klient-programmet måtte bruge.

> Læg mærke til at f.eks. Access bruger * som wildecard, men hvis man
> skal søge via ADO så er det % på samme måde som i SQL eller Oracle.

Tænker du her på rs.Filter eller f.eks. SELECT * FROM T WHERE X LIKE
'ABC%' ?

> Med ADO behøver man ikke at være specifik for given DB - næmmer
> at flytte fra den ene DB til den anden uden at ændre kode
> (kun ConnectionString).

ADO er bedre end ingenting, men jeg synes godt nok at det er lang vej
til noget som bare LIGNER noget som sikrer flytbar kode. Man kommer
meget hurtigt ud i at bruge noget, som er helt database-specifikt.

-------
Tomas

---

"Tomas Christiansen" <toc@blikroer.removethis.dk> wrote:

>Barney Gumble skrev:
>> Med ADO behøver man ikke at være specifik for given DB - næmmer
>> at flytte fra den ene DB til den anden uden at ændre kode
>> (kun ConnectionString).
>
>ADO er bedre end ingenting, men jeg synes godt nok at det er lang vej
>til noget som bare LIGNER noget som sikrer flytbar kode. Man kommer
>meget hurtigt ud i at bruge noget, som er helt database-specifikt.
>

Jeg er helt enig. Jeg har dog et par gange haft fornøjelse af, at ODBC
definerer et fælles datoformat. Det bliver så i driverlaget oversat
til DB-specifikke datoformater, men på kodesiden skal man kun skrive
et enkelt format fx:

   ...SET dte={d '2002-04-29'}...

Se evt. mere på
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcdate__time__and_timestamp_literals.asp