05. september 2014 - 13:09Der er
17 kommentarer og 2 løsninger
insert en dato opfører sig pludseligt mærkeligt.
Jeg tager en dato fra en tekstboks i en form som har formatet kort datoformat, og som har inputmaske 00-00-0000;;_
Så lægger jeg den ned i en variabel der er defineret som en date Dim dato as date
dato = Format([Forms]![FM_book_lokale]![dato], "dd-mm-yyyy", vbMonday, vbFirstFourDays)
SÅ bliver det mærkeligt.
Jeg laver så nogle check for at se om der er en booking af et rum på den dato i det tidsrum der er indtastet. Her bruger jeg dato variablen. Der er 2 mere end illustreret
where1 = "[IDrum]= " & rum & " AND [dato] = #" & dato & "# AND [starttid] <= #" & frakl & "# AND [sluttid] >= #" & frakl & "#" ' kan man finde en post hvor starttiden ligger indenfor starttid og sluttid på rum og dato reswhere1 = DCount("*", "F_rum_paa_dato_og_tid", where1)
hvis der ikke er andre bookinger får brugeren lov til at booke rummet. MEN når jeg inserter
Her bruger jeg også dato, som jeg igen for en sikkerheds skyld formatterer dd-mm-yyyy.
problemet er så at hvis det eks. er d. 8-9-2014, så bliver det lavet om til 9-8-2014
Jeg har debugget, og helt ned til inserten, står den rigtige dato i dato variablen, men når jeg laver insert, så bliver den lavet om, selvom jeg formatterer den i insert sætningen.
Feltet dato i databasen er dato og klokkeslæt type, format kort datoformat inputmaske 00-00-0000;;_
Er der nogen der kan gennemskue problemet ?
Det mærkeligste er at jeg masser andre gange inserter en dato i tabellen, og det virker fint, og selvom jeg kopierer fremgangsmåden så virker det ikke.
Man kan næsten at du har konkluderet dig frem til hvordan det forholder sig - og det man emperisk efterviser er hvad gælder!
Når du anvender dato 'på bogstavelig vis' i sql udtryk skal det skrives på amerikansk: mm-dd-yyyy. Det giver også lidt mening at 'sql engine' ikke er locale afhængig. (nationale konvertioner for tal og datoers skrivemåde)
Hvis vi har en Tabel D med indholdet i datasheet dato 09-08-2014 15-08-2014 Det er d. 9 og 15 august der efter nationale præsentations standarder
sql udtrykket select * from D where dato >= #9-8-2014# giver ikke nogle poster da #9-8-2014# opfattes som d. 8 september
select * from D where dato >= #13-8-2014# kan ikke konverteres efter amerikansk standard, så der en post i select * from D where dato >= #13-8-2014#
select * from D where dato >= cvdate("9-8-2014") viser 2 poster fordi "9-8-2014" IKKE ingår bogstaveligt i sql udtrykket. sql engine modtager et navn på en funktion og parameter hvormed funktionen skal kaldes og bruger funktionens returværdi, en dato, i en sql select betingelse.
At cvdate's argument også kan være et udtryk af typen date, ses at at følgende har 0 poster select * from D where dato >= cvdate(#9-8-2014#)
bvirk, skal jeg forstå det således at når jeg inserter, skal jeg formattere på amerikansk, selvom det er indtastet og står i variablen formatteret på dansk.
så står det på amerikansk i databasen,
OG når jeg eks, skal generere et recordset med select, skal mit kriterie være formatteret på amerikansk ?
Det der er mest mærkeligt er at jeg har hundredevis af entries i den database lavet med et andet modul, som bare virker, hvor jer inserter dato formatteret på dansk, og det står fint, jeg kan søge med kriterier som også er formatteret på dansk, uden problemer. Men lige pludseligt kan jeg ikke gøre det :)
OG når jeg eks, skal generere et recordset med select, skal mit kriterie være formatteret på amerikansk ?
You can format the date as you want. If your PC's regional settings are set to Danish then they will show the data
DDMMYYYY but you can also use the format function to show dates in other formats.
As I mentioned previously, the way a date is stored in the dB is always the same. So as long as you enter it correctly then you can display it as you wish. If you enter it incorrectly then you wont be able to display it correctly no matter how you format it.
kimsand, du har fået svar af terry på hvordan datoer skal være formateret.
Det gælder når datoer skrives bogstaveligt i sql udtrykket. Måske burde man tillægge sig den vane at undgå det hvor det er muligt.
hvis kontrolelementet dato er bundet til felt af typen dato/klokkesæt, burde du kunne skrive: dato = "[Forms]![FM_book_lokale]![dato]"
og så uden #'er om dato
where1 = "[IDrum]= " & rum & " AND [dato] = " & dato & " AND [starttid] <= #" & frakl & "# AND [sluttid] >= #" & frakl & "#" ' kan man finde en post hvor starttiden ligger indenfor starttid og sluttid på rum og dato reswhere1 = DCount("*", "F_rum_paa_dato_og_tid", where1)
I må virkeligt undskylde jeg er sku nok lidt tungnem her... tror ikke jeg forklarer mig rigtigt, eller også så forstår jeg ikke jeres svar, formentligt det sidste.
Det er ligemeget hvordan jeg formatterer, eller om jeg formatterer overhovedet, så laver den en indtastning i et felt 8-9-2014 om til 9-8-2014 når det står i databasen, hvilket betyder at når jeg så refresher den form lige bagefter hvor bookingen skal dukke op, så kommer den ikke for det er en forkert dato.
bvirk, hvad betyder "bogstaveligt" det når du skriver "Det gælder når datoer skrives bogstaveligt i sql udtrykket. Måske burde man tillægge sig den vane at undgå det hvor det er muligt."
Dit løsningsforslag betyder det at variablen dato skal være en streng så den kan indeholde "[Forms]![FM_book_lokale]![dato]"
Nå jeg prøvede at formattere det indtastede i amerikansk format inden jeg lagde det i dato as date variablen.
Det var også det i skrev, det tog mig bare virkeligt lang tid at forstå :)
Det er dog mærkeligt at jeg, i en anden frontend der ved hjælp af løkker opretter tilbud i tilbudskalenderen, ikke har problemet, og ikke formatterer amerikansk inden jeg inserter...
Tak for hjælpen til jer begge. Kan i ikke smide et svar begge to, så deler jeg pointene ?
I cant say why its worked previously although it could be that the month part (what you think is day) of the date has been greater than 12 so Access has assumed that this was the day part. EG 13/09/2014 MM/DD/YYYY access accepts it 13 September becuas ether is no month 13 12/09/2014 would be accepted as 09 December
Det er godt du har fået det virke. Ja det kan godt være indviklet når der pludseligt er flere faktorer end man egentligt har tid til at fordybe sig i. At noget har 'virket før' og noget stadig virker med 'dd-mm' kan betyde at det skal kigges grundigt igennem - manglende '#' tegn kan give udefinerede resultater og datoer som #13/8-2014# forbliver d. 13 august Det nærmest et dogme, at korrekthed ved dato/tidspunkt konverteringer skal testes indgående.
Forespørsler i office access har én, iøvrigt elles unyttig feature - man kan skive en list af expressions helt uden tabelangivelse - prøv denne: select #1/8-2014#-1,#13/8-2014#-1,cvdate("1/8-2014")-1
Bogstaveligt, som i vha. bogstaver, er min oversættelse af litteral (fra andre sammenhænge) - skulle nok snare have været tegnstaveligt ;)
Bemærk hvordan vi i: select dato1 from T where dato1 < dato2
slipper for at udtrykke os i tegnbaserede præsentationsformer. Man kan sige, om de 2 expressions på hver side af '<' tegnet, at evalueringen til værdier af typen date, forgår uden vi med tegn direkte skriver datoer. Vi har nogle referencer, her feltnavne.
Om din [Forms]![FM_book_lokale]![dato] ved jeg ikke om den er gået hen og blevet af type string. Det man teste ved at formen FM_book_lokale åbnes , og herefter spørge på udtrykket: typename([Forms]![FM_book_lokale]![dato]) i en select forespørsel eller ?... i vba editorens immediate vindue
Hvis den er af typen date, er det at 'gå over åen efter vand' med konvertering til tegnstavelige datoer. (#7)
Det har været interessant at skrive dette, for denne 'fejl' har jeg lavet hundrevis af gange - har bevistløst påklistret kald til denne alle mulige steder:
Function amrDate(dat As Date) amrDate = "#" & Format(dat, "mm-dd-yyyy") & "#" End Function
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
