---

jeg har en database med et datofelt som har defineret som:
format: kort datoformat
standardværdi: =now()

Jeg har nu i flere uger prøvet at opdatere datofeltet sammen med resten af
posten, men det nægter feltet.

Jeg bruger:
SQLstringK="UPDATE Entries SET name='"&Request.QueryString("name")&"',
subject='"&Request.QueryString("subject")&"',
comment='"&Request.QueryString("comment")&"', date='" & now() & "' WHERE
id="&id

Er der nogen der vil give et bud på hvad jeg kan gøre anderledes?

SumSum


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.381 / Virus Database: 214 - Release Date: 02-08-2002

---

Ikke fordi jeg har meget forstand på det men på min computer er short date
format ikke li med Now men der i mod Date DD-MM-ÅÅÅÅ altså uden tid, har
sagtens kunne gemme til dette felt ved hjælp af Date.
Håber det hjælper

Mvh.
Nikolaj

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

---

On Wed, 21 Aug 2002 18:32:11 +0200, "SumSum" <motor30@hotmail.com>
wrote:

>jeg har en database med et datofelt som har defineret som:
>format: kort datoformat
>standardværdi: =now()

Hvad datofeltets *format* er, er sådan set ligegyldigt for, hvilken
*værdi* du kan indsætte ...

>Jeg har nu i flere uger prøvet at opdatere datofeltet sammen med resten af
>posten, men det nægter feltet.
>
>Jeg bruger:
>SQLstringK="UPDATE Entries SET name='"&Request.QueryString("name")&"',
>subject='"&Request.QueryString("subject")&"',
>comment='"&Request.QueryString("comment")&"', date='" & now() & "' WHERE
>id="&id

Den interessante del er:

date='" & now() & "'

hvor ' indikerer, at du har med datatypen _tekst_ at gøre - hvilket du
jo ikke har. Prøv at erstatte ' med #, så kan du være heldig at det
virker, måske.
Problemet er, at du gør dig afhængig af dato-*formatet*. Prøv i stedet
at indsætte rene værdier med funktionen nævnt her:
<URL:
http://groups.google.com/groups?hl=da&selm=1879jt0nj8ng3066tpe91bs1frm82c7u2p%404ax.com>

og indsæt så også:

Session.LCID = 1030

i toppen af siden, hvis det fx er dansk du arbejder i.

Se mere her:
<URL:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iisref/html/psdk/asp/eadg9s8i.asp>


>Er der nogen der vil give et bud på hvad jeg kan gøre anderledes?

Håber noget af det kunne lede dig på sporet ...


Good luck!

--
Jørn Andersen,
Brønshøj

---

Jørn Andersen <jorn@jorna.dk> wrote in
news:jg38mu8pt3psbuebfi3kf057vh6vls1a7e@4ax.com:

> On Wed, 21 Aug 2002 18:32:11 +0200, "SumSum" <motor30@hotmail.com>
> wrote:
>
>>jeg har en database med et datofelt som har defineret som:
>>format: kort datoformat standardværdi: =now()
>
> Hvad datofeltets *format* er, er sådan set ligegyldigt for, hvilken
> *værdi* du kan indsætte ...
>
>>Jeg har nu i flere uger prøvet at opdatere datofeltet sammen med resten
>>af posten, men det nægter feltet.
>>
>>Jeg bruger:
>>SQLstringK="UPDATE Entries SET name='"&Request.QueryString("name")&"',
>>subject='"&Request.QueryString("subject")&"',
>>comment='"&Request.QueryString("comment")&"', date='" & now() & "'
>>WHERE id="&id
>
> Den interessante del er:
>
> date='" & now() & "'
>
> hvor ' indikerer, at du har med datatypen _tekst_ at gøre - hvilket du
> jo ikke har. Prøv at erstatte ' med #, så kan du være heldig at det
> virker, måske.
> Problemet er, at du gør dig afhængig af dato-*formatet*. Prøv i stedet
> at indsætte rene værdier med funktionen nævnt her:
> <URL:
> http://groups.google.com/groups?hl=da&selm=1879jt0nj8ng3066tpe91bs1frm82
> c7u2p%404ax.com>
>
> og indsæt så også:
>
> Session.LCID = 1030
>
> i toppen af siden, hvis det fx er dansk du arbejder i.
>
> Se mere her:
> <URL:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iisref/
> html/psdk/asp/eadg9s8i.asp>
>
>
>>Er der nogen der vil give et bud på hvad jeg kan gøre anderledes?
>
> Håber noget af det kunne lede dig på sporet ...
>
>
> Good luck!
>

Ja, det ser ud til at du har en datatype problem.

For det første er det ret farligt for din applikation at du ukritisk
forsøger at putte data direkte fra den submittede form og ned i basen uden
validering. Du burde derimod hente din name, subject & comment ind i en
variabel og test for valid input inden.

Hvis du vil indsætte dags dato i et felt, så brug Date() i stedet for Now
(), fordi Now indeholde klokkeslæt. Du kan formattere med
minDato=FormatDateTime(date(),vbShortDate).

Hvis du putter en dato ned i en Access-base skal du overholde Access'
datoformat: #dato#, altså

UPDATE minTabel SET minDato='#" & dato & "#' WHERE mitKriterie ;

Vær opmærksom på, at "#12-03-2002#" er et tekstfelt for VB, men et datofelt
for Access. Hvis du stadig har problemer, så prøv at konvertere din dato
til datotypen via minDato=CDate(date()) - nu burde VB, ASP og Access være
glade. CDate() verificerer at argumentet faktisk *er* en valid dato, ellers
får du fejl.

Husk at kontrollere datoerne "#10-5-2002#" og "#5-10-2002#" for at se om
din database gemmer i dansk eller engelsk datoformat.



--
Klaus Ambrass

IT - Storstrøms Amt
kam@it.stam.dk

---

"Klaus Ambrass" <kam@it.stam.dk> skrev i en meddelelse
news:Xns92726793E7ABFambrass@212.88.64.226...
> Ja, det ser ud til at du har en datatype problem.
>
> For det første er det ret farligt for din applikation at du ukritisk
> forsøger at putte data direkte fra den submittede form og ned i basen uden
> validering. Du burde derimod hente din name, subject & comment ind i en
> variabel og test for valid input inden.

Det var for at simplificere koden Jeg tester for tilladte tegn inden jeg
gemmer det.

> Hvis du vil indsætte dags dato i et felt, så brug Date() i stedet for Now
> (), fordi Now indeholde klokkeslæt. Du kan formattere med
> minDato=FormatDateTime(date(),vbShortDate).

Jeg skal netop bruge både dato og klokkeslet. Feltet har følgende format:
DD-MM-ÅÅÅÅ HH:MM:SS

> Hvis du putter en dato ned i en Access-base skal du overholde Access'
> datoformat: #dato#, altså
>
> UPDATE minTabel SET minDato='#" & dato & "#' WHERE mitKriterie ;

Virker ikke. Jeg får følgende fejl:

SQL kommando:
update Entries Set comment = 'tester lige', date='#22-08-2002 21:00:52#'
WHERE (Id = 761)

Fejl:
Microsoft OLE DB Provider for ODBC Drivers fejl '80040e14'

[Microsoft][ODBC Microsoft Access-driver] Der er en syntaksfejl i
UPDATE-sætningen.

/avis/forum/editpost2.asp, linje 18

> Vær opmærksom på, at "#12-03-2002#" er et tekstfelt for VB, men et
datofelt
> for Access. Hvis du stadig har problemer, så prøv at konvertere din dato
> til datotypen via minDato=CDate(date()) - nu burde VB, ASP og Access være
> glade. CDate() verificerer at argumentet faktisk *er* en valid dato,
ellers
> får du fejl.

Kan jeg bede om at få det forklaret en gang til? Jeg forstår ikke forskellen
mellem tekstfelt for VB og datofelt for Access.

> Husk at kontrollere datoerne "#10-5-2002#" og "#5-10-2002#" for at se om
> din database gemmer i dansk eller engelsk datoformat.

Formatet stemmer overens med det format, der allerede findes i feltet. Der
står nemlig 22-08-2002 21:00:40 (altså dansk)

Hilsen
SumSum


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.381 / Virus Database: 214 - Release Date: 02-08-2002

---

SumSum skrev:

> SQL kommando:
> update Entries Set comment = 'tester lige', date='#22-08-2002
> 21:00:52#' WHERE (Id = 761)

Prøv at fjerne plingerne omkring datoen:

UPDATE Entries SET comment = 'tester lige', date=#22-08-2002 21:00:52# WHERE (Id = 761)

Så snart der sættes plinger (') omkring indholdet i et felt
vil Access tolke det som tekst.

--
Jens Gyldenkærne Clausen
MF (medlem af FIDUSO - www.fiduso.dk)
I ovenstående tekst benyttes nyt komma.

---

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> skrev i en meddelelse
news:Xns9272D8BF39254jcdmfdk@212.242.40.196...
> Prøv at fjerne plingerne omkring datoen:
>
> UPDATE Entries SET comment = 'tester lige', date=#22-08-2002 21:00:52#
WHERE (Id = 761)

Har jeg nu prøvet:
update Entries Set comment = 'tester lige', date=#22-08-2002 21:15:01# WHERE
(Id = 761)
Microsoft OLE DB Provider for ODBC Drivers fejl '80040e14'
[Microsoft][ODBC Microsoft Access-driver] Der er en syntaksfejl i
UPDATE-sætningen.
/avis/forum/editpost2.asp, linje 31

> Så snart der sættes plinger (') omkring indholdet i et felt
> vil Access tolke det som tekst.

Samme syntaksfejl.

SumSum


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.381 / Virus Database: 214 - Release Date: 02-08-2002

---

"SumSum" <motor30@hotmail.com> wrote in message
news:3d6537c2$0$64850$edfadb0f@dspool01.news.tele.dk...
> "Klaus Ambrass" <kam@it.stam.dk> skrev i en meddelelse
> news:Xns92726793E7ABFambrass@212.88.64.226...
> >
> > Hvis du putter en dato ned i en Access-base skal du overholde Access'
> > datoformat: #dato#, altså
> >
> > UPDATE minTabel SET minDato='#" & dato & "#' WHERE mitKriterie ;
>
> Virker ikke. Jeg får følgende fejl:
>
> [Microsoft][ODBC Microsoft Access-driver] Der er en syntaksfejl i
> UPDATE-sætningen.
>
Hmm, det skal da være?
"UPDATE minTabel SET minDato=#" & dato & "# WHERE mitKriterie"

Prøver jeg i native Access så får jeg en "Type Conversion Failure" hvis der
er enkeltapostroffer før/efter havelågerne

mvh/Peter Lykkegaard

---

"Peter Lykkegaard" <polonline@hotmail.com> skrev i en meddelelse
news:3d6539ea$0$53708$edfadb0f@dspool01.news.tele.dk...
> > > UPDATE minTabel SET minDato='#" & dato & "#' WHERE mitKriterie ;

update Entries Set comment = 'tester lige', date='#22-08-2002 21:21:31#'
WHERE (Id = 761)
Microsoft OLE DB Provider for ODBC Drivers fejl '80040e14'
[Microsoft][ODBC Microsoft Access-driver] Der er en syntaksfejl i
UPDATE-sætningen.
/avis/forum/editpost2.asp, linje 31

> Hmm, det skal da være?
> "UPDATE minTabel SET minDato=#" & dato & "# WHERE mitKriterie"

update Entries Set comment = 'tester lige', date=#22-08-2002 21:22:22# WHERE
(Id = 761)
Microsoft OLE DB Provider for ODBC Drivers fejl '80040e14'
[Microsoft][ODBC Microsoft Access-driver] Der er en syntaksfejl i
UPDATE-sætningen.
/avis/forum/editpost2.asp, linje 31

Det giver præcis samme fejl. Fejlen må vel derfor ligge i at feltet ikke vil
acceptere at værdien ændres eller tager jeg fejl?

SumSUm


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.381 / Virus Database: 214 - Release Date: 02-08-2002

---

"SumSum" <motor30@hotmail.com> wrote in message
news:3d653b9f$0$64896$edfadb0f@dspool01.news.tele.dk...

> update Entries Set comment = 'tester lige', date=#22-08-2002 21:22:22#
WHERE
> (Id = 761)
> Microsoft OLE DB Provider for ODBC Drivers fejl '80040e14'
> [Microsoft][ODBC Microsoft Access-driver] Der er en syntaksfejl i
> UPDATE-sætningen.
> /avis/forum/editpost2.asp, linje 31
>
> Det giver præcis samme fejl. Fejlen må vel derfor ligge i at feltet ikke
vil
> acceptere at værdien ændres eller tager jeg fejl?
>
Hmmm, jeg lavede en minitest før jeg postede mit indlæg for at være sikker
UPDATE SSCCLabel SET SSCCLabel.DateTest = '#12/12/2002#';
Virker _ikke_ (Type Conversion Error)

UPDATE SSCCLabel SET SSCCLabel.DateTest = #12/12/2002#;
Virker og opdaterer tabellen med den foreslåede dato

Fejlen må ligge et andet sted i din Update Query eller i selve formatering
af datoen
Har du mulighed for at afprøve din Query direkte i Access?

Jeg går ud fra at Entries er en tabel med blandt andet felterne ID, Comment,
Date...

Hmmm, nu skriger de sgu til himlen
Date er jo et reserveret ord i Access
Det vil sige du kan _ikke_ bruge Date som feltnavn i din tabel

mvh/Peter Lykkegaard

---

"Peter Lykkegaard" <polonline@hotmail.com> skrev i en meddelelse
news:3d653e6e$0$53633$edfadb0f@dspool01.news.tele.dk...
> Jeg går ud fra at Entries er en tabel med blandt andet felterne ID,
Comment,
> Date...

Jeps

> Hmmm, nu skriger de sgu til himlen
> Date er jo et reserveret ord i Access
> Det vil sige du kan _ikke_ bruge Date som feltnavn i din tabel

Jeg ændrede feltnavnet til datte, for at teste om det var fejlen og så
virkede det. Jeg kysser ydmygt den jord du træder på

En taknemmelig SumSum


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.381 / Virus Database: 214 - Release Date: 02-08-2002

---

On Thu, 22 Aug 2002 21:39:58 +0200, "Peter Lykkegaard"
<polonline@hotmail.com> wrote:

>Date er jo et reserveret ord i Access
>Det vil sige du kan _ikke_ bruge Date som feltnavn i din tabel

Er der ikke noget om, at det kan man godt, men at man blot skal huske
at sætte firkant-parantes om: [date] for at undgå at få syntaks-fejl?
(Har ikke testet fornylig, så ...)

--
Jørn Andersen,
Brønshøj

---

Jørn Andersen skrev:

>>Date er jo et reserveret ord i Access
>>Det vil sige du kan _ikke_ bruge Date som feltnavn i din tabel
>
> Er der ikke noget om, at det kan man godt, men at man blot
> skal huske at sætte firkant-parantes om: [date] for at undgå
> at få syntaks-fejl? (Har ikke testet fornylig, så ...)

Jo - men det kan ikke anbefales. Feltnavne der kræver []-er for at
blive fortolket korrekt er noget juks.


--
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

---

On Fri, 23 Aug 2002 09:50:54 +0200, "Jens Gyldenkærne Clausen"
<jens@gyros.invalid> wrote:

>Feltnavne der kræver []-er for at
>blive fortolket korrekt er noget juks.

Det er jeg slet ikke uenig i.
Spørgsmålet var kun, om man kunne


--
Jørn Andersen,
Brønshøj

---

Som svar på skriblerier nedfældet af Jørn Andersen :

> On Fri, 23 Aug 2002 09:50:54 +0200, "Jens Gyldenkærne Clausen"
> <jens@gyros.invalid> wrote:
>
>> Feltnavne der kræver []-er for at
>> blive fortolket korrekt er noget juks.
>
> Det er jeg slet ikke uenig i.
> Spørgsmålet var kun, om man kunne

Jamen, det kan da sagtens
Tabel-/feltnavne kan også være A, B, C, D

mvh/Peter Lykkegaard

---

Jens Gyldenkærne Clausen wrote in news:Xns9273642F6A83Djcdmfdk@
193.88.15.213:

> Jo - men det kan ikke anbefales. Feltnavne der kræver []-er for at
> blive fortolket korrekt er noget juks.

hvorfor egentlig det ? Der er svjv ikke noget standards-mæssigt i vejen med
det - det kan kun være ud fra nogle æstetiske overvejelser ... eller ?

--
Jesper Stocholm
http://stocholm.dk
(der har været ikke-ryger i hele 7 dage)
Svar til gruppen og ikke til mig privat pr. email :|

---

Som svar på skriblerier nedfældet af Jesper Stocholm :

> Jens Gyldenkærne Clausen wrote in news:Xns9273642F6A83Djcdmfdk@
> 193.88.15.213:
>
>> Jo - men det kan ikke anbefales. Feltnavne der kræver []-er for at
>> blive fortolket korrekt er noget juks.
>
> hvorfor egentlig det ? Der er svjv ikke noget standards-mæssigt i
> vejen med det - det kan kun være ud fra nogle æstetiske overvejelser
> ... eller ?

Man har jo heller variabler der hedder i, j, k, object, date etc

Med en _fornuftig_ navngivnings konvention kommer _ikke_ man ud for at
skulle bruge Date som attribut navn

Brug af reserverede ord er lig med timers debugning for at finde en runtime
error før eller siden

Just my two cents

- Peter Lykkegaard

---

Peter Lykkegaard wrote in news:x4n99.31$up6.469@news.get2net.dk:

> Som svar på skriblerier nedfældet af Jesper Stocholm :
>
>> Jens Gyldenkærne Clausen wrote in news:Xns9273642F6A83Djcdmfdk@
>> 193.88.15.213:
>>
>>> Jo - men det kan ikke anbefales. Feltnavne der kræver []-er for at
>>> blive fortolket korrekt er noget juks.
>>
>> hvorfor egentlig det ? Der er svjv ikke noget standards-mæssigt i
>> vejen med det - det kan kun være ud fra nogle æstetiske overvejelser
>> ... eller ?
>
> Man har jo heller variabler der hedder i, j, k, object, date etc

nej ... men det er imo heller ikke det samme .. og i øvrigt vil jeg skyde
på, at variabel-navnene i,j,k ... bruges i mindst 90% af alle programmer,
hvor der skal gennemløbes løkker eller lignende.



> Med en _fornuftig_ navngivnings konvention kommer _ikke_ man ud for at
> skulle bruge Date som attribut navn

Jeg vil holde på, at det er mere vigtigt at give sigende felt-navne - end
at bekymre sig om hvorvidt det er et reserveret ord eller ej. Det
klassiske eksempel - i hvert fald for danske brugere - er opgaven med at
lave en adressebog i fx Access. Med denne opgave er det overvejende
sandsynligt at man kommer til at skulle bruge et felt med navnet "By".
Her vil jeg mene, at det giver bedre og mere overskuelig kode at vedblive
at kalde det "By" ... i stedet for at bytte det ud med et andet ord, der
ikke er reserveret.

Endelig: jeg vil godt understrege, at jeg self. ikke mener, at man
ukritisk skal navngive sine felter med ord som
SELECT,FROM,WHERE,BY,TIME,DATE etc. Jeg blev blot irriteret over det
kategoriske udsagn "Feltnavne der kræver []-er for at blive fortolket
korrekt er noget juks." ... som om det var den evigt gyldige sandhed. Det
er det nemlig ikke. Det vil - som det jo altid er tilfældet i forbindelse
med planlægning af en opgave - komme an på de medfølgende ulember og
fordele. Først når disse er belyste kan det vurderes om det er "noget
juks" eller ej.



--
Jesper Stocholm
http://stocholm.dk
(der har været ikke-ryger i hele 7 dage)
Svar til gruppen og ikke til mig privat pr. email :|

---

Som svar på skriblerier nedfældet af Jesper Stocholm :

> Peter Lykkegaard wrote in news:x4n99.31$up6.469@news.get2net.dk:
>
>> Som svar på skriblerier nedfældet af Jesper Stocholm :
>>
>> Man har jo heller variabler der hedder i, j, k, object, date etc
>
> nej ... men det er imo heller ikke det samme .. og i øvrigt vil jeg
> skyde på, at variabel-navnene i,j,k ... bruges i mindst 90% af alle
> programmer, hvor der skal gennemløbes løkker eller lignende.
>
Jeg falder så i gruppen på de sidste 10%, indrømmet det var en lidt "grov"
sammenligning

>> Med en _fornuftig_ navngivnings konvention kommer _ikke_ man ud for
>> at skulle bruge Date som attribut navn
>
> Jeg vil holde på, at det er mere vigtigt at give sigende felt-navne -
> end at bekymre sig om hvorvidt det er et reserveret ord eller ej.

Hvad ville du gøre hvis du skulle bruge By eller Date i 10 forskellige
tabeller?

Med navnekonvention tænkte jeg på brug af prefix/suffix
Fx
txtBy, txtDate, dtmDate (MSAccess)
varBy, varDate, sdtDate eller dtmDate (MSSQL)
Blot nogle samples

Det er én måde at gøre det på

Ellers kunne man bruge dette
tblAdresse
adrOprettet, adrBy

Ved den sidste metode (som jeg selv bruger) så kan man hurtigt se hvor
(hvilken tabel) et given felt stammer fra
Mht reserverede ord så er jeg selv flere gange rendt ind i problemer ved
konvertering fra Access til MSSQL
I den sammenhæng vil jeg også lige advare mod brug af æøå i tabel/feltnavne,
da er dette uværgeligt giver problemer på et eller andet tidspunkt

mvh/Peter Lykkegaard

---

Peter Lykkegaard wrote in news:9io99.43$up6.771@news.get2net.dk:

> Som svar på skriblerier nedfældet af Jesper Stocholm :
>
>> Peter Lykkegaard wrote in news:x4n99.31$up6.469@news.get2net.dk:
>>> Man har jo heller variabler der hedder i, j, k, object, date etc
>>
>> nej ... men det er imo heller ikke det samme .. og i øvrigt vil jeg
>> skyde på, at variabel-navnene i,j,k ... bruges i mindst 90% af alle
>> programmer, hvor der skal gennemløbes løkker eller lignende.
>>
> Jeg falder så i gruppen på de sidste 10%, indrømmet det var en lidt
> "grov" sammenligning

np ... jeg har faktisk - hvis jeg skal kigge lidt "indad" - oplevet, at jeg
er begyndt og bruge navne som fx intI,intJ til disse løbende variabel-
navne.

>>> Med en _fornuftig_ navngivnings konvention kommer _ikke_ man ud for
>>> at skulle bruge Date som attribut navn
>>
>> Jeg vil holde på, at det er mere vigtigt at give sigende felt-navne -
>> end at bekymre sig om hvorvidt det er et reserveret ord eller ej.
>
> Hvad ville du gøre hvis du skulle bruge By eller Date i 10 forskellige
> tabeller?
>
> Med navnekonvention tænkte jeg på brug af prefix/suffix
> Fx
> txtBy, txtDate, dtmDate (MSAccess)
> varBy, varDate, sdtDate eller dtmDate (MSSQL)
> Blot nogle samples
>
> Det er én måde at gøre det på

og det er præcist det jeg mener ... altså mere sigende variabel-navne, der
- som du skriver - fx fortæller om datatypen eller hvilken tabel den
stammer fra [1]. Men så er målet jo mere overskuelig kode - ligesom tricket
med eksplicit at skrive alle felter man hente ud fra en database i stedet
for *-angivelsen - og ikke at man ikke må bruge reserverede ord. Så mange
ord er der altså heller ikke - og mht skiftet imellem forskellige database-
typer, så vil jeg påstå at den mindste opgave i en overgang fra ét system
til et andet er kontrol at felt-navne. Det er blot at finde listen over
reserverede ord frem og så kigge koden igennem. Målet er jo - som du selv
siger - mere overskuelig kode. Men hvis dette kan nås ved at kalde et felt
for "FROM", så kan jeg altså ikke se noget galt i dette.

[1] Husk dog på, at ligegyldigt hvor "logisk" din metode ser ud, så skal
det med i dokumentationen, så andre kan læse din kode et år senere :) Jeg
har selv problemet med noget kode som jeg f****** selv har skrevet - i min
purunge ungdom - men jeg har nu store problemer med at læse koden. Jeg kan
huske, at jeg tænkte, at det ville være logisk at kalde mine SQL-strenge
for sql1,sql2,sql3 ... men pludselig skulle jeg bruge en ny SQL-streng inde
imellem ... så den kom til at hedde strSQL_01 ... og sådan videre ... :)

[2] Baseret på talrige erfaringer med at skifte fra MSAccess til MySQL,
MSAccess til MSSQL, MSAccess til TeraData,MSSQL til TeraData,MySQL til
MSSQL,MSSQL til ORACLE8 etc ... etc ... etc ... :)

--
Jesper Stocholm
http://stocholm.dk
http://asp.stocholm.dk
Svar til gruppen og ikke til mig privat pr. email :|

---

Som svar på skriblerier nedfældet af Jesper Stocholm :

> Så mange ord er der altså heller ikke - og mht skiftet imellem
> forskellige database- typer, så vil jeg påstå at den mindste
> opgave i en overgang fra ét system til et andet er kontrol at
> felt-navne.

Tænk, hvis du netop _ikke_ havde behov for at skulle den tur igennem

Det er rimeligt nemt, men også lidt træls når man skal løbe adskillige
linier kildekode og et større antal formularer igennem for at ændre fx
"Lærer" til "Laerer"

mvh/Peter Lykkegaard

---

Jesper Stocholm skrev:

>> Man har jo heller variabler der hedder i, j, k, object, date
>> etc

> ...vil jeg skyde på, at variabel-navnene i,j,k ... bruges i
> mindst 90% af alle programmer, hvor der skal gennemløbes
> løkker eller lignende.

Jeg er med i de 90 %.


> Jeg blev blot irriteret over det kategoriske udsagn "Feltnavne
> der kræver []-er for at blive fortolket korrekt er noget
> juks." ... som om det var den evigt gyldige sandhed. Det er
> det nemlig ikke.


Det har jeg vist heller ikke hævdet. Alle mine skriblerier er
udtryk for personlige meninger - ikke eviggyldige sandheder.
Men min mening i denne sag er vist ikke helt usædvanlig. De bøger
jeg har brugt omkring SQL har entydigt anbefalet en navngivning der
ikke kræver hjælpetegn.

--
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

---

Jesper Stocholm skrev:

>> Jo - men det kan ikke anbefales. Feltnavne der kræver []-er
>> for at blive fortolket korrekt er noget juks.
>
> hvorfor egentlig det ? Der er svjv ikke noget
> standards-mæssigt i vejen med det - det kan kun være ud fra
> nogle æstetiske overvejelser ... eller ?

Nej - det er overvejende praktiske overvejelser. Sandsynligheden
for at man på et tidspunkt glemmer at escape feltnavnet er ikke
ubetydelig. Og hvis koden skal læses/ændres af andre er der endnu
større mulighed for fejl. Samtidig mener jeg også at det er noget
vanskeligere at læse (i hånden).

Det er anden gang inden for et par måneder at jeg er stødt på en
sql-fejl på grund af feltnavnet Date - men selvom jeg fulgte med i
den første tråd og tænkte "åh ja" i det øjeblik løsningen dukkede
lykkedes det mig alligevel at overse at det var samme problem i
denne sammenhæng.

Du har givetvis ret i at der ikke er nogen standarder der direkte
forbyder brugen af reserverede ord som feltnavne (eller feltnavne
med mellemrum for den sags skyld). Men alle de bøger om databaser
jeg har læst har frarådet at gøre det - med nogenlunde de samme
begrundelser som jeg har nævnt her.


--
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

---

"Jørn Andersen" <jorn@jorna.dk> skrev i en meddelelse
news:jg38mu8pt3psbuebfi3kf057vh6vls1a7e@4ax.com...
> Den interessante del er:
>
> date='" & now() & "'
>
> hvor ' indikerer, at du har med datatypen _tekst_ at gøre - hvilket du
> jo ikke har. Prøv at erstatte ' med #, så kan du være heldig at det
> virker, måske.

Har jeg prøvet, men det giver samme syntaksfejl

> Problemet er, at du gør dig afhængig af dato-*formatet*. Prøv i stedet
> at indsætte rene værdier med funktionen nævnt her:
> <URL:
>
http://groups.google.com/groups?hl=da&selm=1879jt0nj8ng3066tpe91bs1frm82c7u2
p%404ax.com>

Har jeg også prøvet. Giver følgende:

update Entries Set comment = 'tester lige', date=DateSerial(2002, 8, 22) +
TimeSerial(21, 17, 31) WHERE (Id = 761)
Microsoft OLE DB Provider for ODBC Drivers fejl '80040e14'
[Microsoft][ODBC Microsoft Access-driver] Der er en syntaksfejl i
UPDATE-sætningen.
/avis/forum/editpost2.asp, linje 31

> og indsæt så også:
> Session.LCID = 1030

er gjort, men datoen står stadig som ÅÅÅÅ,M,DD, hvor den før stod som
DD-MM-ÅÅÅÅ HH:MM:SS

> <URL:
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iisref/html
/psdk/asp/eadg9s8i.asp>

Det forstod jeg desværre ikke meget af, men datetosql funktionen giver
alligevel ikke det resultat, jeg er ude efter. Det gør NOW() til gengæld.

SumSum


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.381 / Virus Database: 214 - Release Date: 02-08-2002