---

Hej

Jeg har det problem at jeg har lavet et asp script der søger i en
access database, men scriptet timer ud.

Jeg har sat følgende:

Server.ScriptTimeout=600 og conn.commandtimeout=600

Men når jeg afvikler det på min server, så timer det ud, men hvis
jeg kører det på min pc, så virker det fint nok.

Er der nogen der kan fortælle mig hvad jeg evt. kan gøre for at
afhjælpe fejlen?

Hilsen Johnny

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

---

"JonZ" <jonz@ofir.dk> skrev
>
> Jeg har det problem at jeg har lavet et asp script der søger i en
> access database, men scriptet timer ud.
>
> Jeg har sat følgende:
>
> Server.ScriptTimeout=600 og conn.commandtimeout=600
>
> Men når jeg afvikler det på min server, så timer det ud, men hvis
> jeg kører det på min pc, så virker det fint nok.
>
> Er der nogen der kan fortælle mig hvad jeg evt. kan gøre for at
> afhjælpe fejlen?

Du kører måske i en uendelig løkke...
Du må komme med noget kode...
Bjarne

---

bsn wrote in dk.edb.internet.webdesign.serverside.asp:
>
> Du kører måske i en uendelig løkke...
> Du må komme med noget kode...
> Bjarne
>
>
Jeg ville heller end gerne smide alt min kode her, jeg ved bare ikke
hvad der er for en del af koden jeg skal smide.

Som jeg også skrev i mit oprindelige indlæg, så virker samme kode fint
hvis jeg kører det på min pc, men så snart jeg smider det over på min
server, så virker det ikke.

Men her er min sql:

set rs = conn.execute("select * from opkaldud where dato >= " &
datetosql(cp1) & " and dato <= " & datetosql(cp2) & " and tidspunkt >=
#" & cp3 & "# and tidspunkt <= #" & cp4 & "# order by dato " )
if rs.eof then
response.redirect "tidsrumform.asp?error=Der blev ikke fundet nogle
resultater."

Det skal måske siges at det er en accessdatabase og der er ca. 130.000
poster i databasen.

Måske det nærmere er fordi jeg skal over i en anden gruppe. hmm

Hilsen Johnny

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

---

JonZ wrote:

> Som jeg også skrev i mit oprindelige indlæg, så virker samme kode fint
> hvis jeg kører det på min pc, men så snart jeg smider det over på min
> server, så virker det ikke.
>
> Men her er min sql:
>
> set rs = conn.execute("select * from opkaldud where dato >= " &
> datetosql(cp1) & " and dato <= " & datetosql(cp2) & " and tidspunkt >=
> #" & cp3 & "# and tidspunkt <= #" & cp4 & "# order by dato " )
> if rs.eof then

En server burde være hurtigere end en PC?
Men
1) Du burde overveje at lave et datetime felt i stedet for at skille dato og
kl. ad.
2) Hvis du bibeholder dato og tid for sig, så lav et index på begge felter:
Sql'et = "CREATE idx_opkald on opkaldud(dato,tidspunkt)"

> Det skal måske siges at det er en accessdatabase og der er ca. 130.000
> poster i databasen.

Med den rette indexering burde det ikke væree et problem.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote in dk.edb.internet.webdesign.serverside.asp:
>
> En server burde være hurtigere end en PC?
> Men
> 1) Du burde overveje at lave et datetime felt i stedet for at skille dato og
> kl. ad.

Jeg kan ikke lave et nye felt der indeholder begge, det er en database jeg får
fra en leverandør.

> > Det skal måske siges at det er en accessdatabase og der er ca. 130.000
> > poster i databasen.
>
> Med den rette indexering burde det ikke væree et problem.

Det er måske dette jeg skal prøve.


Tak indtil videre

Hilsen Johnny

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

---

On 03 Mar 2008 11:16:02 GMT, JonZ <jonz@ofir.dk> wrote:

>Men her er min sql:
>
>set rs = conn.execute("select * from opkaldud where dato >= " &
>datetosql(cp1) & " and dato <= " & datetosql(cp2) & " and tidspunkt >=
>#" & cp3 & "# and tidspunkt <= #" & cp4 & "# order by dato " )

Ikke at det er fejlen, men for at gøre fejlsøgning lettere, så ville det
være bedre at omskrive til:

strSql = "SELECT bla bla"
Set rs = Conn.Execute strSql

Så kan du nemlig udskrive din SQL-streng med:

Response.Write strSql
Response.End
- inden: Set rs ...

Et par spørgsmål:
Hvor mange poster forventer du, at denne forespørgsel returnerer?

Har dine felter "dato" og "tidspunkt" typen Date/Time?
Er felterne indekserede?

Du kan evt. (til testformål) begrænse din søgning ved at tilføje en
betingelse a la " AND Id < 1000" - hvis der er et Id-felt.
På den måde finder du ud af, om den faktisk gennemfører
SQL-forespørgslen - og om det er i forespørgslen eller i din
udskrifts-loop det går galt.

Hvis den virker med en snævrere søgning, kan du fx udvide søgningen og
se, hvor langt du kan gå op, før det går galt.

Alternativt kan du prøve at "skære af" din udskriftsloop - fx nøjes med
at udskrive et simpelt felt pr. post. Eller sætte den til at gå ud af
loopen efter 20 udksrevne poster.
Hvis den gennemføres relativt hurtigt, vil det give dig en indikation i
retning af, at det er din udskrifts-loop, der tager for lang tid.

<snip>
>Det skal måske siges at det er en accessdatabase og der er ca. 130.000
>poster i databasen.

Det er sådan set ikke et problem. Det største problem med Access er
antal connections, ikke antal poster eller hastighed.

>Måske det nærmere er fordi jeg skal over i en anden gruppe. hmm

Det tror jeg ikke nødvendigvis. Men det er svært at give konkrete svar
på den slags spørgsmål uden flere oplysninger.

Du kan evt. uploade din kode på din server - giv blot .asp-filen en
..txt-ekstension. Sørg dog for at anonymisere de ting, der ikke kommer
andre ved.

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

---

Jørn Andersen wrote:

> Du kan evt. uploade din kode på din server - giv blot .asp-filen en
> .txt-ekstension. Sørg dog for at anonymisere de ting, der ikke kommer
> andre ved.

Nå, vi har nok skrevet ca. samtidig ;)

Ud over det du skriver, kunne det også være relevant med en beskrivelse af
tabellen "opkaldud ".

Det er nemt at programmere, men det er noget nær en dødssynd at bruge:
"select * from"

Så forholdet mellem de felter der bliver _udtaget_ fra databasen i forhold
til de felter man skal _bruge_ kunne muligvis være interessant.

Det er muligt det ikke har den store betydning mht Access men på _rigtige_
databaser har det stor betydning, specielt hvis der indgår blob fields.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote in dk.edb.internet.webdesign.serverside.asp:

> Ud over det du skriver, kunne det også være relevant med en beskrivelse af
> tabellen "opkaldud ".
>
> Det er nemt at programmere, men det er noget nær en dødssynd at bruge:
> "select * from"
>
> Så forholdet mellem de felter der bliver _udtaget_ fra databasen i forhold
> til de felter man skal _bruge_ kunne muligvis være interessant.
>
> Det er muligt det ikke har den store betydning mht Access men på _rigtige_
> databaser har det stor betydning, specielt hvis der indgår blob fields.
>

Jeg må prøve dette, jeg troede bare ikke det havde den store betydning. Skal
lige siges at jeg ikke ved så meget om databaser. Kun sådan lidt til
husbehov.

Nu snakker både dig og Jørn om indeksering. Hvordan gør man det?

Hilsen Johnny

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

---

On 04 Mar 2008 17:01:52 GMT, JonZ <jonz@ofir.dk> wrote:

>> Det er nemt at programmere, men det er noget nær en dødssynd at bruge:
>> "select * from"
<snip>

>Jeg må prøve dette, jeg troede bare ikke det havde den store betydning.

Som Stig skriver: Det kommer an på ...
Men derudover har det også den fordel, at det gør koden lettere at
gennemskue, når man skal kigge på den 5 måneder senere.

>Nu snakker både dig og Jørn om indeksering. Hvordan gør man det?

Jge er heller ikke database-ekspert, men som jeg forstår det, bør alle
de fleter, som indgår i din "WHERE"-del bør være indekserede.
Indeksering bruger ekstra tid, når tabellen opdateres (fordi der skal
sættes indeks), men forkorter søgetiden - nogle gange *meget*
væsentligt.
I dit tilfælde burde et ikke være et problem, idet du modtager en
færdigt opdateret database,(som jeg forstår det).

Åbn tabellen i designvisning og kig så på hver enkelt felts egenskaber.
Auto-nummer-felter og Dato/Tid-felter er som default indekserede, mens
tal- og tekst-felter ikke er.
Hvis de to felter står til:
Indexed: No
- så kan du ændre det til:
Indexed: Yes (Duplicates OK)


Hvilket bringer mig til det spørgsmål, du *ikke* svarede på, nemlig om
dine dato- og tid-felter er i Date/Time-format?

Jeg kunne mistænke, at de er i tekst-format og ikke indekserede. Det kan
sagtens være grunden til dit problem. Dels fordi de ikke er indekserede,
men også fordi der skal laves tekst-sammenligning på hvert enkelt felt,
hvilket tager urimeligt lang tid.

Du vil helt klart vinde *meget* ved at have dato-tid-felter i
Date/Time-format.
Hvis ikke du kan få kunden til at levere i det rigtige format (for dato
og tid er Date/Time så at sige altid det eneste rigige format), så lav
en opdateringsforespørgsel, som beregner en *ægte* Dato/Tid ud fra dine
2 adskilte felter (til et nyt felt).
Den skal kun køres én gang, hver gang du modtager en database, så det
burde være til at overkomme.

Som sagt er det kun et gæt, da jeg ikke ved noget om din
tabel-opbygning.

Good luck!

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

---

Jørn Andersen wrote:

> On 04 Mar 2008 17:01:52 GMT, JonZ <jonz@ofir.dk> wrote:
>
>>> Det er nemt at programmere, men det er noget nær en dødssynd at bruge:
>>> "select * from"
> <snip>
>
>>Jeg må prøve dette, jeg troede bare ikke det havde den store betydning.

"Select *" betyder, at man udtager alle felter i en tabel = over i memory.
Så hvis du har en tabel med felterne:
felt1
felt2
felt3
felt4
felt5
felt6
... osv
Så vil en select * returnere
felt1, felt2,felt3,felt4,felt5,felt6 osv. i dit "rs" objekt.

Hvis man kun skal bruge fetl3 og felt 4 til udskrift bør man skrive
select felt3,felt4 from.., og det vil så returnere
felt3,felt4

Dvs. i ovenstående eksempel returneres
felt1,fel2,fejlt5,felt6 osv. som overflødige data fra databasen til memory.
Og det gælder for *hver eneste* rs.MoveNext.
Det med blob fields hedder 'memo' i min engelske Assces, er det 'noat' p
dansk?

Men denne type kræver mange gentagne interne kald for at hente data til
recordsettet (= dit rs)

>>Nu snakker både dig og Jørn om indeksering. Hvordan gør man det?

Se længere nede.

> Jge er heller ikke database-ekspert,

Ekspert blive man vel aldrig, men man har da småpillet med
databaseprogrammering siden '82.

> men som jeg forstår det, bør alle
> de fleter, som indgår i din "WHERE"-del bør være indekserede.

Korrekt, men men kun der WHERE hvor det er >,=,< osv.
På som LIKE og Funktioner har indexering ingen værdi.

> Indeksering bruger ekstra tid, når tabellen opdateres (fordi der skal
> sættes indeks),

Det er også korrekt, men traditionelt har det først betydning når man kommer
over 2-3 indexer.

> men forkorter søgetiden - nogle gange *meget*
> væsentligt.

Det er også korrekt, og man skal, som du selv skriver, afveje behovet i
forhold til skrivning og læsning.

Typisk med Datawarehouse databaser, der kun opdateres en gang imellem, har
det ingen betydning med performance ved skrivning.
Derimod har performace ved læsning meget stor betydning, så typisk er der
*mange* indexer på sådan en satan.

> I dit tilfælde burde et ikke være et problem, idet du modtager en
> færdigt opdateret database,(som jeg forstår det).
>
> Åbn tabellen i designvisning og kig så på hver enkelt felts egenskaber.
> Auto-nummer-felter og Dato/Tid-felter er som default indekserede, mens
> tal- og tekst-felter ikke er.
> Hvis de to felter står til:
> Indexed: No
> - så kan du ændre det til:
> Indexed: Yes (Duplicates OK)

Det er een måde at gøre det på. Men det giver to indexer, hor der jfr.
Johnny's sql kun er brug for et.

De indbyggede funktioner i MSAccess kan ikke håndtere det der hedder
compound indexes, men det kan 'JET' driveren.
Hvis man benytter SQL via Jet driveren, kan Access *meget* mere end folk
tror.

Heriblandt compound indexes.

Med hensyn til 'hvordan', gav jeg svaret, men burde nok have uddybet:
Jeg skrev:
> Sql'et = "CREATE idx_opkald on opkaldud(dato,tidspunkt)"

Dermed mente jeg, at Johnny bare skal fyre den her af i ASP'et:
conn.execute(""CREATE idx_opkald on opkaldud(dato,tidspunkt)")
Bemærk, da der ikke returneres et resultset skal der ikke 'set rs=' på.
Navnet 'idx_opkald' er valgfrit, der må bare ikke eksistere 2 indexer med
samme navn.

For en god ordwns skyld vil jeg nævne, at jeg har aftestet det på Access97,
dog med andre feltnavne.

Det skal kun gøres een gang, men hvis Johnny løbende modtager databaser,
skal det gøres hver gang ham modtager en ny.

Ved at bruge compound index, altså en indexering på både dato og tid, opnår
man samme virkning som et helst datetime felt.

Hvis man ikke har brug for at søge på klokkelslet alene er der ingen grund
til andre indexes.

Heller ikke de 2 du nævner.

> Hvilket bringer mig til det spørgsmål, du *ikke* svarede på, nemlig om
> dine dato- og tid-felter er i Date/Time-format?

Nu skal man måske passe på hvad man siger, men bemærkede du '#'erne i
sql'et?

--
Med venlig hilsen
Stig Johansen

---

On Wed, 05 Mar 2008 07:47:47 +0100, Stig Johansen
<stig_johansen_it_at_=(@)hotmail.com> wrote:

>Det er een måde at gøre det på. Men det giver to indexer, hor der jfr.
>Johnny's sql kun er brug for et.
<snip>
>conn.execute(""CREATE idx_opkald on opkaldud(dato,tidspunkt)")

Tak, så fattede selv jeg den - og blev klogere

<snip>

>> Hvilket bringer mig til det spørgsmål, du *ikke* svarede på, nemlig om
>> dine dato- og tid-felter er i Date/Time-format?
>
>Nu skal man måske passe på hvad man siger, men bemærkede du '#'erne i
>sql'et?

Det burde jeg nok have gjort - men da der også var indbygget en
ASP-funktion, var det en af grundene til, at jeg gerne ville have
udskrevet SQL'en.


Mvh. Jørn

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

---

On Wed, 05 Mar 2008 07:47:47 +0100, Stig Johansen
<stig_johansen_it_at_=(@)hotmail.com> wrote:

>Det er een måde at gøre det på. Men det giver to indexer, hor der jfr.
>Johnny's sql kun er brug for et.

<snip>
>> Hvilket bringer mig til det spørgsmål, du *ikke* svarede på, nemlig om
>> dine dato- og tid-felter er i Date/Time-format?
>
>Nu skal man måske passe på hvad man siger, men bemærkede du '#'erne i
>sql'et?

Lige en ekstra overvejelse:
Hvis begge felter er Dato/Tid-felter (og indekseret sammen), giver det
så ikke et problem?

Jeg mener: Selv om det kun er dato-værdien fra den ene og tids-værdien
fra den anden, der er interessante, så indeholder begge Dato/Tid-felter
jo både en dato- og en tid-komponent (uanset om den bliver vist eller
anvendt).

Jeg kan ikke gennemskue, om det er et problem, men umiddelbart synes jeg
det er "noget snask" - og et argument for at konvertere de to felter til
ét felt, som indeholder den "sande" dato/tid-værdi.

Er det mig, der ser spøgelser?


Mvh. Jørn

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

---

Jørn Andersen wrote:

> Lige en ekstra overvejelse:
> Hvis begge felter er Dato/Tid-felter (og indekseret sammen), giver det
> så ikke et problem?

Nej.

> Jeg mener: Selv om det kun er dato-værdien fra den ene og tids-værdien
> fra den anden, der er interessante, så indeholder begge Dato/Tid-felter
> jo både en dato- og en tid-komponent (uanset om den bliver vist eller
> anvendt).

Ikke helt dato tid 'komponent'. Nu kender jeg ikke det interne dato/tid
format i Access, men det er i virkeligheden bare et tal.

I 'noget andet' bruger man typisk bare et kommatal - eksempelvis
39512,700106 (= da heg skrev)
De 39512 er antal dage siden, vistnok 31/12/1899 og 0,700106 er en brøk at
de 24 timer inden for en dag.
Så klokken er 16 (24*0,700106) osv.
Antal sekunder siden midnat er: 24*60*60 * 0,700106

Jeg sidder tilføldigvis og roder med nogle logviler i Access, hor dato og
tid er skilt i to felter.

Det interne format i databaser er ligegyldigt, men hvis det var det samme,
ville mit datofelt indeholde 39512,0 og mit tidsfelt indeholde 0,700106

> Jeg kan ikke gennemskue, om det er et problem, men umiddelbart synes jeg
> det er "noget snask" - og et argument for at konvertere de to felter til
> ét felt, som indeholder den "sande" dato/tid-værdi.

Son nævnt har jeg adskilte felter lDate for dato og lTime for klokken.
Når man skal se antal log's pr dag for at kigge på udviklingen bruger
jeg:dette SQL:
select lDate AS Dato,Count(*) AS Nbr from logfile GROUP BY ldate ORDER BY
ldate

Et andet sted, hvor jeg gerne vil se på hvilke tidspunkter (i timer) der er
aktivitet bruger jeg dette SQL:
SELECT Left(CStr(lTime),2) AS atHour, Count(*) AS Nbr
FROM xmllogfile
GROUP BY Left(CStr(lTime),2)
ORDER BY Left(CStr(lTime),2)

I begge tilfælde er Count(*) en funktion, og i dette tilfælde er det bedst
at bruge '*'.

> Er det mig, der ser spøgelser?

Ja, du skal nærmere tænke:
Ingen indexer --> det hele står i en pærevælling, og _samtlige_ 130.000
poster skal ledes igennem.
Index på dato, ej tid --> Datoindexet er sortetet, så poster inden for
datoen findes 'straks', men men alle posterne inden for dagen skal ledes
igennem for at frinde fra - til kl.
Compound Index på både dato og tid --> Compound Index er sorteret på både
dato og tid, så posterne inden for Johnny's interval findes 'straks'.

Et index er en fysisk 'tabel' i databasen, der indeholder en sorteret række
(aka b-tree), samt pointere til de enkrlte rækker.

Håber det gav lidt uddybning.

--
Med venlig hilsen
Stig Johansen

---

> Stig Johansen wrote
> Jørn Andersen wrote:


Hej Stig og Jørn

I skal begge have 1000 tak for hjælpen indtil nu, jeg er jo blevet en del
klogere nu "tror jeg da" jeg vil lige teste jeres forslag og løsninger i
næste uge, hvis det ikke virker så vil jeg vende tilbage med fornyet styrke og
nye spørgsmål.


Hilsner og igen tak.

Johnny



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

---

Stig Johansen wrote in dk.edb.internet.webdesign.serverside.asp:
>
> Med hensyn til 'hvordan', gav jeg svaret, men burde nok have uddybet:
> Jeg skrev:
> > Sql'et = "CREATE idx_opkald on opkaldud(dato,tidspunkt)"
>
> Dermed mente jeg, at Johnny bare skal fyre den her af i ASP'et:
> conn.execute(""CREATE idx_opkald on opkaldud(dato,tidspunkt)")
> Bemærk, da der ikke returneres et resultset skal der ikke 'set rs=' på.
> Navnet 'idx_opkald' er valgfrit, der må bare ikke eksistere 2 indexer med
> samme navn.
>
Hej Stig

Jeg fik lige lidt tid nu, og så prøvede jeg lige ovenstående. Men du har
lavet en syntax fejl. Enten er der et " for meget eller for lidt. Jeg har
prøvet at fjerne det ene. Men det gav følgende fejl.

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'

[Microsoft][ODBC Microsoft Access Driver] Syntax error in CREATE TABLE
statement.

/periode/ind.asp, line 4

Linje 4 ser således ud:

conn.execute ("CREATE idx_opkald on opkaldud(dato,tidspunkt)")

Jeg har også prøvet at sætte et ind, man det bliver ved med at fejle. Håber
du kan hjælpe.

Hilsen Johnny.

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

---

JonZ wrote:

> conn.execute ("CREATE idx_opkald on opkaldud(dato,tidspunkt)")
>
> Jeg har også prøvet at sætte et ind, man det bliver ved med at fejle.
> Håber du kan hjælpe.

Nåh ja, sorry - sikke nget sjusk.

Det skal være "CREATE INDEX idx_opkald on opkaldud(dato,tidspunkt"

Ked af smutteren.

--
Med venlig hilsen
Stig Johansen

---

Jørn Andersen wrote in dk.edb.internet.webdesign.serverside.asp:

>
> Ikke at det er fejlen, men for at gøre fejlsøgning lettere, så ville det
> være bedre at omskrive til:
>
> strSql = "SELECT bla bla"
> Set rs = Conn.Execute strSql
>
> Så kan du nemlig udskrive din SQL-streng med:
>
> Response.Write strSql
> Response.End
> - inden: Set rs ...

Ja det ved jeg, men jeg har ikke brug for at udskrive min sql-streng. Men
tak for rådet.
>
> Et par spørgsmål:
> Hvor mange poster forventer du, at denne forespørgsel returnerer?

Jeg ved ikke helt hvor mange, men mange.

>
> Har dine felter "dato" og "tidspunkt" typen Date/Time?
> Er felterne indekserede?

Nej de er sikkert ikke indekseret.


>
> Du kan evt. (til testformål) begrænse din søgning ved at tilføje en
> betingelse a la " AND Id < 1000" - hvis der er et Id-felt.
> På den måde finder du ud af, om den faktisk gennemfører
> SQL-forespørgslen - og om det er i forespørgslen eller i din
> udskrifts-loop det går galt.
>
> Hvis den virker med en snævrere søgning, kan du fx udvide søgningen og
> se, hvor langt du kan gå op, før det går galt.

Den virker fint, hvis jeg kun søger på 5 dage, så får jeg resultater.

>
> Alternativt kan du prøve at "skære af" din udskriftsloop - fx nøjes med
> at udskrive et simpelt felt pr. post. Eller sætte den til at gå ud af
> loopen efter 20 udksrevne poster.
> Hvis den gennemføres relativt hurtigt, vil det give dig en indikation i
> retning af, at det er din udskrifts-loop, der tager for lang tid.

Jeg tror jeg skal prøve at udelade select * og i stedet kun finde de
felter jeg skal bruge.

Tak for hjælpen indtil nu.

Hilsen Johnny

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