---

Jeg har et problem med et program, hvor Response.flush ikke virker, men jeg
kan ikke se, hvad der forhindrer det!

Programmet laver databaseopslag, og er i hovedtrækker et således:
svar.open soegestr,Conn
Do While Not svar.EOF
response.flush
---
En flok statement med
---
Response.flush
svar.MoveNext
Loop
Response.flush
Svar.close

Er der noget, man skal undgå, for at Response.flush kan virke?

Kurt

---

"Kurt G" <kurt_g@guldbaek.net> skrev i en meddelelse
news:48ee4c10$0$90270$14726298@news.sunsite.dk...

> Er der noget, man skal undgå, for at Response.flush kan virke?

<table>
do while....
<tr><td>
Et eller andet
</td></tr>
Flush()
loop
</table>
Din browser vil sikkert ikke udskrive tabellen før den får </table>
Jeg har ikke prøvet det, men CSS position i stedet for table vil måske kunne
løse det.

mvh
Erling

---

Erling Sørensen wrote:

> Din browser vil sikkert ikke udskrive tabellen før den får </table>
> Jeg har ikke prøvet det, men CSS position i stedet for table vil måske
> kunne løse det.

Et andet fif jeg plejer at bruge ved lange tabeller(lister) er at dele dem
op i 'sider'.
Dvs i stedet for een stor table, så et antal tables á eks. 50.
Så starter renderingen ved den første </table>.

Det giver brugerne en lidt mere 'fed' oplevelse af svartider.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:

> Det giver brugerne en lidt mere 'fed' oplevelse af svartider.

Glemte lige.
Man skal heller ikke flushe for tit.
Det giver anledning til ekstra trafik mellem server og browser
(=langsommere).
Standard MTU er 1500 bytes incl overhead, så man skal ikke gå under eks.
1400 bytes/flush.

Men det er som sagt irrellevant at flushe indtil </table>.
Hvis der altså er tale om en <table>.
Det fremgår ikke af Kurt's post, men er nok et kvalificeret gæt ud fra hans
sidste srpøgsmål.

--
Med venlig hilsen
Stig Johansen

---

"Stig Johansen" <wopr.dk@gmaill.com> skrev i en meddelelse
news:48eed9ad$0$90263$14726298@news.sunsite.dk...
> Erling Sørensen wrote:
>
>> Din browser vil sikkert ikke udskrive tabellen før den får </table>
>> Jeg har ikke prøvet det, men CSS position i stedet for table vil måske
>> kunne løse det.
>
> Et andet fif jeg plejer at bruge ved lange tabeller(lister) er at dele dem
> op i 'sider'.
> Dvs i stedet for een stor table, så et antal tables á eks. 50.
> Så starter renderingen ved den første </table>.
>
> Det giver brugerne en lidt mere 'fed' oplevelse af svartider.
>
> --
> Med venlig hilsen
> Stig Johansen

Jeg var faktisk efter meget bøvl kommet frem til, at det ikke virkede inde i
den tabel, som jeg havde det i, så I havde ret!
Men jeg kan vel ikke redde det ved at lave flere tabeller, for det er inde i
en anden tabel for at få ikke-scrollende overskrifter efter den opskrift,
som du fortalte mig om 6.10 i html-gruppen.
Så jeg må nok vende tilbage til en almindelig formateret udskrift, og så
tilføje overskrifter efter et vist antal linier. Det er ærgerligt, for det
så langt bedre ud i tabelformatet!

Tak til jeg begge!

Mvh Kurt

---

"Erling Sørensen" <erling_deletethis@nvn.dk> skrev i en meddelelse
news:48eeca05$0$56791$edfadb0f@dtext02.news.tele.dk...
>
> "Kurt G" <kurt_g@guldbaek.net> skrev i en meddelelse
> news:48ee4c10$0$90270$14726298@news.sunsite.dk...
>
>> Er der noget, man skal undgå, for at Response.flush kan virke?
>
> <table>
> do while....
> <tr><td>
> Et eller andet
> </td></tr>
> Flush()
> loop
> </table>
> Din browser vil sikkert ikke udskrive tabellen før den får </table>
> Jeg har ikke prøvet det, men CSS position i stedet for table vil måske
> kunne løse det.
>
> mvh
> Erling

Jeg har gjort forskellige forsøg, og som du siger, vil response.flush først
virke efter *den sidste* </table> er gennemført. Det er rigtig
irriterende!!!
Kunne du uddybe det med 'css position' lidt mere!

Mvh Kurt

---

"Kurt G" <kurt_g@guldbaek.net> skrev i en meddelelse
news:48ef3fee$0$90276$14726298@news.sunsite.dk...
> "Erling Sørensen" <erling_deletethis@nvn.dk> skrev i en meddelelse
> news:48eeca05$0$56791$edfadb0f@dtext02.news.tele.dk...
>>
>> "Kurt G" <kurt_g@guldbaek.net> skrev i en meddelelse
>> news:48ee4c10$0$90270$14726298@news.sunsite.dk...
>>
>>> Er der noget, man skal undgå, for at Response.flush kan virke?

[snip]
>> Din browser vil sikkert ikke udskrive tabellen før den får </table>
>> Jeg har ikke prøvet det, men CSS position i stedet for table vil måske
>> kunne løse det.

[snip]
> Kunne du uddybe det med 'css position' lidt mere!

Det er jeg bange for jeg IKKE kan. Som nævnt har jeg faktisk ikke rigtig
prøvet det, men har dog en fornemmelse af det ville kunne fåes til at
fungere.
Se evt. her: http://www.html.dk/tutorials/css/lektion14.asp
Eller her: http://www.w3schools.com/css/css_positioning.asp
Eller evt. Google :)
Så vidt jeg husker, er det ikke alle undertyper af position som understøttes
i alle browsere.
Hvilke det er kan jeg ikke lige komme i tanker om, så tjek i hver fald
siderne med både IE og FF.

mvh
Erling

---

"Kurt G" <kurt_g@guldbaek.net> wrote in message
news:48ef3fee$0$90276$14726298@news.sunsite.dk...
> Jeg har gjort forskellige forsøg, og som du siger, vil response.flush
først
> virke efter *den sidste* </table> er gennemført. Det er rigtig
> irriterende!!!

Det er ikke Response.flush, der ikke virker, der er browseren der ikke
begynder at 'tegne' tabellen før den er afsluttet.

Kunne du ikke skrive lidt om hvad din 'udfordring' er ?

Jeg har lige lavet et 'prøveudtræk' fra en Access DB hvor der er 1784 rækker
i den resulterende tabel, og sammenlagt er der 645.885 bytes i html'et jfr.
Firefox.
Det tager ca. 1 sekund på min 850 MHz PC.

Kan det tænkes, at dit html er 'unødigt' kompliceret ?

--
Med venlig hilsen/Best regards
Stig Johansen

---

"Stig Johansen" <wopr.dk@gmail.com> skrev i en meddelelse
news:48efd5d1$0$90264$14726298@news.sunsite.dk...
> "Kurt G" <kurt_g@guldbaek.net> wrote in message
> news:48ef3fee$0$90276$14726298@news.sunsite.dk...
>> Jeg har gjort forskellige forsøg, og som du siger, vil response.flush
> først
>> virke efter *den sidste* </table> er gennemført. Det er rigtig
>> irriterende!!!
>
> Det er ikke Response.flush, der ikke virker, der er browseren der ikke
> begynder at 'tegne' tabellen før den er afsluttet.

Ja, det kan jeg også se på de blink, der er i led for internettrafik!

> Kunne du ikke skrive lidt om hvad din 'udfordring' er ?

Jeg vil gerne have et udtræk fra en database, hvor kolonneoverskrifterne
ikke scroller op, når man scroller ned i tabellen med svarene.

> Jeg har lige lavet et 'prøveudtræk' fra en Access DB hvor der er 1784
> rækker
> i den resulterende tabel, og sammenlagt er der 645.885 bytes i html'et
> jfr.
> Firefox.
> Det tager ca. 1 sekund på min 850 MHz PC.
>
> Kan det tænkes, at dit html er 'unødigt' kompliceret ?

Ja, i den retning kan alt tænkes, under processen har der været prøvet
meget! Men jeg har da prøvet at gøre den stringent her til sidst!

Jeg har lavet flere udgaver, den, som jeg i øjeblikket arbejder på, kan
findes her:
http://www.slara.dk/Historisk/Index.htm/AarbogsIndex/SoegeStart.asp.
Herfra vælger man videre!

Koden er her:

http://www.slara.dk/Historisk/Index.htm/AarbogsIndex/Kode.htm

Jeg har prøvet at lave et udtræk med alle mine stikord, der er omkring
13.000 linier, og det tager 50 sekunder. Det er langt over den normale
tålmodighedsgrænse!
Men inden jeg er færdig, er der nok omkring 20.000 stikordslinier
Men på den anden side er der jo sjældent nogen, der ønsker at se alle
stikord og med normale svarantal, som jeg forventer, tager det nok kun
omkring 3 sekunder. Det kan man jo nok leve med!

Mvh Kurt

---

Der var lige et Index.htm/ for meget!
Her er der rettet.

> Jeg har lavet flere udgaver, den, som jeg i øjeblikket arbejder på, kan
> findes her:
> http://www.slara.dk/Historisk/AarbogsIndex/SoegeStart.asp.
> Herfra vælger man videre!
>
> Koden er her:
>
> http://www.slara.dk/Historisk/AarbogsIndex/Kode.htm
>

> Mvh Kurt
>

---

Kurt G wrote:

>> Koden er her:
>>
>> http://www.slara.dk/Historisk/AarbogsIndex/Kode.htm

Jeg skal lige have kigget lidt nærmere, men en ting der springer umiddelbart
i øjnene er din optælling af antal.
Der looper du igennem for at finde antallet.

Antallet finder du ved at benytte COUNT i forespørgslen.

Her kan du i stedet starte med at bruge (bemærk ej ORDER BY) her:
sqlcount = "SELECT COUNT(*) AS Antal FROM Samlet " & soegestr
set svar = Conn.Execute "SELECT COUNT(*) AS Antal FROM Samlet " & soegestr
I = svar("Antal")
svar.Close

..... videre kode og definere med sortering:
soegestr = "SELECT * FROM Samlet " & soegestr & " Order by Stikord, Aar"

Vender tilbage på et tidspunkt med forslag til optimeret HTML/CSS/ASP, men
det tager 'lidt tid'.

--
Med venlig hilsen
Stig Johansen

---

Det med Count var jeg godt klar over, men jeg kunne ikke huske koden. Det
tager nu heller ikke alverdens tid.
Men overskriften må kunne laves med 'normal' tekst og så må man kunne lave
en kasse af en eller anden art, hvor man viser tabellerne inden i. Man kan
jo lave en ny tabel for hver gang man har f.eks. 20 poster og derved få
response.flush til at virke!
Det vil jeg forsøge at kikke på.

Mvh Kurt

"Stig Johansen" <wopr.dk@gmaill.com> skrev i en meddelelse
news:48f0c881$0$90271$14726298@news.sunsite.dk...
> Kurt G wrote:
>
>>> Koden er her:
>>>
>>> http://www.slara.dk/Historisk/AarbogsIndex/Kode.htm
>
> Jeg skal lige have kigget lidt nærmere, men en ting der springer
> umiddelbart
> i øjnene er din optælling af antal.
> Der looper du igennem for at finde antallet.
>
> Antallet finder du ved at benytte COUNT i forespørgslen.
>
> Her kan du i stedet starte med at bruge (bemærk ej ORDER BY) her:
> sqlcount = "SELECT COUNT(*) AS Antal FROM Samlet " & soegestr
> set svar = Conn.Execute "SELECT COUNT(*) AS Antal FROM Samlet " & soegestr
> I = svar("Antal")
> svar.Close
>
> .... videre kode og definere med sortering:
> soegestr = "SELECT * FROM Samlet " & soegestr & " Order by Stikord, Aar"
>
> Vender tilbage på et tidspunkt med forslag til optimeret HTML/CSS/ASP, men
> det tager 'lidt tid'.
>
> --
> Med venlig hilsen
> Stig Johansen

---

"Kurt G" <kurt_g@guldbaek.net> wrote in message
news:48f0cce1$0$90269$14726298@news.sunsite.dk...
> Det med Count var jeg godt klar over, men jeg kunne ikke huske koden. Det
> tager nu heller ikke alverdens tid.

Næh, men når man har arbejdet med EDB i snart 30 år, så piner det lidt 'den
gamles' øjne .

> Men overskriften må kunne laves med 'normal' tekst og så må man kunne lave
> en kasse af en eller anden art, hvor man viser tabellerne inden i.
Ja, jeg fedtede med noget lignende hvor jeg lavede overskrifterne som en
tabel med een række.
Derefter en <div> med en tabel med 'resten'.

>Man kan
> jo lave en ny tabel for hver gang man har f.eks. 20 poster og derved få
> response.flush til at virke!

Uanset hvad vil jeg nok anbefale dig at optimere dit HTML og CSS.
Du sætter width på hver enkelt celle, og genererer en <p> i hver.
Det giver en masse arbejde til browseren med at bygge noder i DOM træet, og
sætte properties på hver enkelt.

Jeg har gemt - og strikket et eksempel her:
http://w-o-p-r.dk/test/visstikord.asp.htm
med lidt høkertricks.
Bredderne har jeg defineret ved at lægge <col> ind i tabellerne, her hedder
de wordd1..wordd6 (navnene er bare copy/pasted, så kald dem hvad du vil).

De står oppe <head> sektionen hvis du laver en 'vis kilde'.

Et andet trick er at bruge <th> til de celler der skal være centreret, da
det er default.
(Bemærk - jeg har kun rettet de første 2 linier).
Det giver dog en fed skrift, så derfor:
#indre th {font-weight:normal}
som sætter den til normal vægt.
Det virker i Konqueror og Firefox, men min IE6 centrerer også <td>, så af
hensyn til IE6 får den også denne her:
#indre td {text-align:left}

Jeg vil foreslå dig at prøve disse ting først.
Ved at fjerne alle attributterne til <td> og fjerne alle <p>'erne inde i
<td>'erne faldt størrelsen på min kopi til ca 50%.
Ved at fjerne <p>'erne halvere man også antallet af nodes.

Jeg vil gætte på det bliver mindst dobbelt så hurtigt, måske endda mere.

--
Med venlig hilsen/Best regards
Stig Johansen

---

"Stig Johansen" <wopr.dk@gmail.com> skrev
---KLIP---
> Uanset hvad vil jeg nok anbefale dig at optimere dit HTML og CSS.
> Du sætter width på hver enkelt celle, og genererer en <p> i hver.
> Det giver en masse arbejde til browseren med at bygge noder i DOM træet,
> og
> sætte properties på hver enkelt.
>
> Jeg har gemt - og strikket et eksempel her:
> http://w-o-p-r.dk/test/visstikord.asp.htm
> med lidt høkertricks.
> Bredderne har jeg defineret ved at lægge <col> ind i tabellerne, her
> hedder
> de wordd1..wordd6 (navnene er bare copy/pasted, så kald dem hvad du vil).
> De står oppe <head> sektionen hvis du laver en 'vis kilde'.

Jeg har kikket på kildeteksten for siden og der er for mig nogle uklarheder:

Hvor skal jeg anbringe wordd1..wordd6, inden loop i data eller inde efter
<% Do While Not svar.EOF

Kurt

---

Kurt G wrote:

> Jeg har kikket på kildeteksten for siden og der er for mig nogle
> uklarheder:
>
> Hvor skal jeg anbringe wordd1..wordd6, inden loop i data eller inde efter
> <% Do While Not svar.EOF

Før loopet.
Du har:
<div id="inner">
<table id="indre" style="border-collapse: collapse" border="1">
..... HER ....
<%
Do While Not svar.EOF
%> <tr>
......

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:

> Før loopet.
- osv.

Men hvis du har mulighed for at lægge en zippet version af databasen ud, så
kunne det være interessant at bruge den/det som en slags "performance
study".

Kriteriet er, at et eventuelt "performance study" bliver postet hér i
gruppen, så fremtidige "Googlere" får glæde af det.

--
Med venlig hilsen
Stig Johansen

---

"Stig Johansen" <wopr.dk@gmaill.com> skrev i en meddelelse
news:48f1cd2e$0$90274$14726298@news.sunsite.dk...
> Stig Johansen wrote:
>
>> Før loopet.
> - osv.
>
> Men hvis du har mulighed for at lægge en zippet version af databasen ud,
> så
> kunne det være interessant at bruge den/det som en slags "performance
> study".
>
> Kriteriet er, at et eventuelt "performance study" bliver postet hér i
> gruppen, så fremtidige "Googlere" får glæde af det.
>
> --
> Med venlig hilsen
> Stig Johansen

Det skal jeg gerne gøre, men hvor vil du gerne have den?
Jeg må vel ikke lægge den som en vedhæftet fil her i gruppen!

Kurt

---

Databasen ligger her
http://www.slara.dk/Historisk/AarbogsIndex/Databasen.htm

Mvh Kurt

"Stig Johansen" <wopr.dk@gmaill.com> skrev i en meddelelse
news:48f1cd2e$0$90274$14726298@news.sunsite.dk...
> Stig Johansen wrote:
>
>> Før loopet.
> - osv.
>
> Men hvis du har mulighed for at lægge en zippet version af databasen ud,
> så
> kunne det være interessant at bruge den/det som en slags "performance
> study".
>
> Kriteriet er, at et eventuelt "performance study" bliver postet hér i
> gruppen, så fremtidige "Googlere" får glæde af det.
>
> --
> Med venlig hilsen
> Stig Johansen

---

"Kurt G" <kurt_g@guldbaek.net> wrote in message
news:48f26d3a$0$90264$14726298@news.sunsite.dk...
> Databasen ligger her
> http://www.slara.dk/Historisk/AarbogsIndex/Databasen.htm

Ok, den var ikke så stor(MB) som jeg frygtede.
Jeg har optimeret lidt på SQL og HTML
http://w-o-p-r.dk/test/VisStikord.asp
(NB: Der gik lidt ged i layoutet).
Optimeringen af SQL gav fra 450 mS ren svartid til 145 mS.
Den totale svartid på min IE6 ligger dog over 20 sek, hvilket er
uantageligt.
Vi skal helst ned på et sek før brugeren begynder at se noget.

Hvis vi laver et SPT og siger ~12.000 på 30 sek, så vil det nok være
nogenlunde passende at 'flække' tabellen for hver 400 records.

Jeg har kun lige sat det op, og kigget kort for at se hvad vej 'vi' skal gå.
Så tag det som en indledende tilbagemelding.

Vender tilbage når jeg har fundet nogle ting frem jeg skal bruge, men det er
ikke sikkert det bliver før i aften/morgen.

--
Med venlig hilsen/Best regards
Stig Johansen

---

"Stig Johansen" <wopr.dk@gmail.com> skrev i en meddelelse
news:48f2e698$0$90267$14726298@news.sunsite.dk...
> Ok, den var ikke så stor(MB) som jeg frygtede.
> Jeg har optimeret lidt på SQL og HTML
> http://w-o-p-r.dk/test/VisStikord.asp
> (NB: Der gik lidt ged i layoutet).

Ja, det er et andet problem, som jeg tumler med, men det er næppe ASP,
derfor har jeg ventet.

> Optimeringen af SQL gav fra 450 mS ren svartid til 145 mS.
> Den totale svartid på min IE6 ligger dog over 20 sek, hvilket er
> uantageligt.

Det er vel 'transporttid' for ADSL-forbindelsen!

> Vi skal helst ned på et sek før brugeren begynder at se noget.
>
> Hvis vi laver et SPT

hvad er det?

og siger ~12.000 på 30 sek, så vil det nok være
> nogenlunde passende at 'flække' tabellen for hver 400 records.
>
> Jeg har kun lige sat det op, og kigget kort for at se hvad vej 'vi' skal
> gå.
> Så tag det som en indledende tilbagemelding.
>
> Vender tilbage når jeg har fundet nogle ting frem jeg skal bruge, men det
> er
> ikke sikkert det bliver før i aften/morgen.

OK, jeg er efterlønner, og har principielt uendelig megen tid til rådighed.
:-]

---

Kurt G wrote:

> "Stig Johansen" <wopr.dk@gmail.com> skrev i en meddelelse
> news:48f2e698$0$90267$14726298@news.sunsite.dk...
>> Optimeringen af SQL gav fra 450 mS ren svartid til 145 mS.
>> Den totale svartid på min IE6 ligger dog over 20 sek, hvilket er
>> uantageligt.
>
> Det er vel 'transporttid' for ADSL-forbindelsen!

Det er jeg ikke heeelt sikker på (har 8/2Mbps)

En wget siger:
......
sj@lwork1> wget http://w-o-p-r.dk/test/VisStikord.asp
--16:33:08-- http://w-o-p-r.dk/test/VisStikord.asp
=> `VisStikord.asp'
Resolving w-o-p-r.dk... done.
Connecting to w-o-p-r.dk[195.41.131.61]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
[ <=> ] 2,071,819 657.76K/s
16:33:12 (657.76 KB/s) - `VisStikord.asp' saved [2071819]
......
Dvs ca. 4 sek i transporttid incl. skrivning til disk.

>> Vi skal helst ned på et sek før brugeren begynder at se noget.
>>
>> Hvis vi laver et SPT
>
> hvad er det?

Undskyld, nogle gange tager man det for indforstået, men - SPT = Slag På
Tasken - beregning, eller afrundet, så det er lettere at lave
'hovedregning'

> og siger ~12.000 på 30 sek, så vil det nok være
>> nogenlunde passende at 'flække' tabellen for hver 400 records.

Og det var for jeg selv kunne finde ud af at 12 / 3 = 4, jfr. SPT
metoden

--
Med venlig hilsen
Stig Johansen

---

"Stig Johansen" >> news:48f2e698$0$90267$14726298@news.sunsite.dk...
>>> Optimeringen af SQL gav fra 450 mS ren svartid til 145 mS.
>>> Den totale svartid på min IE6 ligger dog over 20 sek, hvilket er
>>> uantageligt.
>>
>> Det er vel 'transporttid' for ADSL-forbindelsen!
>
> Det er jeg ikke heeelt sikker på (har 8/2Mbps)

Er der så andet end behandlingen i selve PC-en tilbage?

>
> En wget siger:
> .....
> sj@lwork1> wget http://w-o-p-r.dk/test/VisStikord.asp
> --16:33:08-- http://w-o-p-r.dk/test/VisStikord.asp
> => `VisStikord.asp'
> Resolving w-o-p-r.dk... done.
> Connecting to w-o-p-r.dk[195.41.131.61]:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: unspecified [text/html]
> [ <=> ] 2,071,819 657.76K/s
> 16:33:12 (657.76 KB/s) - `VisStikord.asp' saved [2071819]
> .....
> Dvs ca. 4 sek i transporttid incl. skrivning til disk.
>
Men tilbage er vel kun at få response.flush til at virke, dvs at lave
kortere (og flere) tabeller eller ikke anvende tabeller til formateringen
(hvilket nok også tager for meget procestid)!

Mvh Kurt

---

Kurt G wrote:

> "Stig Johansen" >> news:48f2e698$0$90267$14726298@news.sunsite.dk...
>>>> Optimeringen af SQL gav fra 450 mS ren svartid til 145 mS.
>>>> Den totale svartid på min IE6 ligger dog over 20 sek, hvilket er
>>>> uantageligt.
>>>
>>> Det er vel 'transporttid' for ADSL-forbindelsen!
>>
>> Det er jeg ikke heeelt sikker på (har 8/2Mbps)
>
> Er der så andet end behandlingen i selve PC-en tilbage?

Det er netop behandlingen i PC'en det handler om.
Som nævnt er svartiden 145mS - dvs. indtil PC'en begynder at modtage data
fra serveren.

> Men tilbage er vel kun at få response.flush til at virke,

Response.flush betyder ikke noget i denne sammenhæng, hele bufferen er
færdig på de 145 mS, så det eneste man kan hente dér er et par
millisekunder.

> dvs at lave
> kortere (og flere) tabeller eller ikke anvende tabeller til formateringen

Præcis.

> (hvilket nok også tager for meget procestid)!

Den samlede tid kan vi ikke gøre noget ved, men brugeroplevelsen kan vi gøre
noget ved.
Bare det, at der dukker noget op - rimeligt hurtigt - betyder noget
(psykologisk).

Jeg har brygget lidt om på strukturen, og 'opløftet' det til xhtml, og brugt
det som en slags skabelon:
<http://w-o-p-r.dk/test/visstikord.asp.htm>
Det er relativt vigtigt at angive en DOCTYPE, som fortæller browseren lidt
om hvad det er for noget der ligger i dokumentet.

Skabelonen har jeg så brugt som 'programoplæg', og lavet - noget af det -
her:
<http://w-o-p-r.dk/test/visstikord.asp>
Her er formattering af overskrifter og bund dog ikke 'færdig' - det vil jeg
overlade til dig.

Hastighed er det lidt smag og behag.
Jeg startede med 'klodser' af 400, men det syntes jeg gik lidt for langsomt.
100 er ok, men 50 er måske bedre.
Du kan justere størrelsen af 'klodserne' i denne linie:
if Recordcounter MOD 50 = 0 then
så det passer til din(dine brugeres) smag.

Men stadigvæk - den samlede tid før siden er 'færdig' kan vi ikke rigtig
gøre noget ved.

Det visuelle er ikke rigtig mit metier, så det skal kun betragtes som et
forslag til funktionel løsning, ikke nødvendigvis designmæssigt korrekt.

Koden er her:
<http://w-o-p-r.dk/test/visstikord.asp.txt>
Der er vist noget med, at visse IE ikke viser det som tekst.
Hvis du ikke får vist kildekoden skal du bruge 'vis kilde'.

Nu kan du se om du kan bruge det, men om ikke andet er der lidt impulser til
videre arbejde.

--
Med venlig hilsen
Stig Johansen

---

Så fik jeg igen leveret på et sølvfad. Du gør dig snart fortjent til et par
flasker rødvin (men de er ikke til at sende ad denne kanal)!
Rigtig ange tak for indsatsen!

Mvh Kurt

"Stig Johansen" <wopr.dk@gmaill.com> skrev i en meddelelse
news:48f38b33$0$90264$14726298@news.sunsite.dk...
> Kurt G wrote:
>
>> "Stig Johansen" >> news:48f2e698$0$90267$14726298@news.sunsite.dk...
>>>>> Optimeringen af SQL gav fra 450 mS ren svartid til 145 mS.
>>>>> Den totale svartid på min IE6 ligger dog over 20 sek, hvilket er
>>>>> uantageligt.
>>>>
>>>> Det er vel 'transporttid' for ADSL-forbindelsen!
>>>
>>> Det er jeg ikke heeelt sikker på (har 8/2Mbps)
>>
>> Er der så andet end behandlingen i selve PC-en tilbage?
>
> Det er netop behandlingen i PC'en det handler om.
> Som nævnt er svartiden 145mS - dvs. indtil PC'en begynder at modtage data
> fra serveren.
>
>> Men tilbage er vel kun at få response.flush til at virke,
>
> Response.flush betyder ikke noget i denne sammenhæng, hele bufferen er
> færdig på de 145 mS, så det eneste man kan hente dér er et par
> millisekunder.
>
>> dvs at lave
>> kortere (og flere) tabeller eller ikke anvende tabeller til formateringen
>
> Præcis.
>
>> (hvilket nok også tager for meget procestid)!
>
> Den samlede tid kan vi ikke gøre noget ved, men brugeroplevelsen kan vi
> gøre
> noget ved.
> Bare det, at der dukker noget op - rimeligt hurtigt - betyder noget
> (psykologisk).
>
> Jeg har brygget lidt om på strukturen, og 'opløftet' det til xhtml, og
> brugt
> det som en slags skabelon:
> <http://w-o-p-r.dk/test/visstikord.asp.htm>
> Det er relativt vigtigt at angive en DOCTYPE, som fortæller browseren lidt
> om hvad det er for noget der ligger i dokumentet.
>
> Skabelonen har jeg så brugt som 'programoplæg', og lavet - noget af det -
> her:
> <http://w-o-p-r.dk/test/visstikord.asp>
> Her er formattering af overskrifter og bund dog ikke 'færdig' - det vil
> jeg
> overlade til dig.
>
> Hastighed er det lidt smag og behag.
> Jeg startede med 'klodser' af 400, men det syntes jeg gik lidt for
> langsomt.
> 100 er ok, men 50 er måske bedre.
> Du kan justere størrelsen af 'klodserne' i denne linie:
> if Recordcounter MOD 50 = 0 then
> så det passer til din(dine brugeres) smag.
>
> Men stadigvæk - den samlede tid før siden er 'færdig' kan vi ikke rigtig
> gøre noget ved.
>
> Det visuelle er ikke rigtig mit metier, så det skal kun betragtes som et
> forslag til funktionel løsning, ikke nødvendigvis designmæssigt korrekt.
>
> Koden er her:
> <http://w-o-p-r.dk/test/visstikord.asp.txt>
> Der er vist noget med, at visse IE ikke viser det som tekst.
> Hvis du ikke får vist kildekoden skal du bruge 'vis kilde'.
>
> Nu kan du se om du kan bruge det, men om ikke andet er der lidt impulser
> til
> videre arbejde.
>
> --
> Med venlig hilsen
> Stig Johansen

---

"Stig Johansen" <wopr.dk@gmail.com> skrev i en meddelelse
news:48f2e698$0$90267$14726298@news.sunsite.dk...
>
> Ok, den var ikke så stor(MB) som jeg frygtede.
> Jeg har optimeret lidt på SQL og HTML
> http://w-o-p-r.dk/test/VisStikord.asp
> (NB: Der gik lidt ged i layoutet).
Ud over formatteringen har jeg også undret mig over, at der er en tom linie
i toppen. Den er det heller ikke lykkedes mig at finde årsagen til.

Mvh Kurt

---

On Sat, 11 Oct 2008 17:37:56 +0200, Stig Johansen <wopr.dk@gmaill.com>
wrote:

>Jeg skal lige have kigget lidt nærmere, men en ting der springer umiddelbart
>i øjnene er din optælling af antal.
>Der looper du igennem for at finde antallet.
>
>Antallet finder du ved at benytte COUNT i forespørgslen.

Eller ved at bruge:

intAntal = objRs.RecordCount

- hvilket sparer en ekstra forespørgsel, men kræver at man ikke bruger
en forward-only cursor (som er default).

<url: http://www.w3schools.com/ado/prop_rs_recordcount.asp>


Mvh. Jørn

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

---

Jørn Andersen wrote:

> Eller ved at bruge:
>
> intAntal = objRs.RecordCount
>
> - hvilket sparer en ekstra forespørgsel, men kræver at man ikke bruger
> en forward-only cursor (som er default).

Hvis det er i orden med dig - så findes der _ikke_ (og vil _aldrig_ findes)
et endegyldigt svar på antallet af entries i en given tabel.

Antag at vi har en tabel med f.eks. 10 entries.
Uanset hvilken metode man bruger, så vil eksempelvis
"SELECT COUNT(*) FROM Tabelnavn"[1], eller udtage et client dataset[2] -
give 10.
Lad os så antage at vi præsenterer resultatet med 'der er 10 udvalgte
poster'.
Samtidig er der en anden bruger, der har oprettet en 11'te post.
Scenarie [1] er, at der fremkommer 11 resultater i stedet for 10.
Scenarie [2] er, at der bliver vist 10 resultater, hvor nr. 11 mangler.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:

> Hvis det er i orden med dig - så findes der _ikke_ (og vil _aldrig_
> findes) et endegyldigt svar på antallet af entries i en given tabel.

Shit - lad mig lige omformulere det.
Erstat
"antallet af entries"
med
"antallet af entries _på forhånd_"

--
Med venlig hilsen
Stig Johansen

---

On Sun, 12 Oct 2008 11:42:37 +0200, Stig Johansen <wopr.dk@gmaill.com>
wrote:

>Jørn Andersen wrote:
>> intAntal = objRs.RecordCount
>>
>> - hvilket sparer en ekstra forespørgsel, men kræver at man ikke bruger
>> en forward-only cursor (som er default).
>
>Hvis det er i orden med dig - så findes der _ikke_ (og vil _aldrig_ findes)
>et endegyldigt svar på antallet af entries i en given tabel.

Det er helt OK med mig.

>Antag at vi har en tabel med f.eks. 10 entries.
>Uanset hvilken metode man bruger, så vil eksempelvis
>"SELECT COUNT(*) FROM Tabelnavn"[1], eller udtage et client dataset[2] -
>give 10.
>Lad os så antage at vi præsenterer resultatet med 'der er 10 udvalgte
>poster'.
>Samtidig er der en anden bruger, der har oprettet en 11'te post.
>Scenarie [1] er, at der fremkommer 11 resultater i stedet for 10.
>Scenarie [2] er, at der bliver vist 10 resultater, hvor nr. 11 mangler.

Det kan så være et ekstra argument for at bruge objRs.RecordCount, da
man så har sikret sig overensstemmelse mellem det antal poster, der
udskrives på siden, og det antal, man skriver er udskrevet.


Mvh. Jørn

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

---

Jørn Andersen wrote:

> Det kan så være et ekstra argument for at bruge objRs.RecordCount, da
> man så har sikret sig overensstemmelse mellem det antal poster, der
> udskrives på siden, og det antal, man skriver er udskrevet.

Det kan vi nok godt få en diskussion ud af :)

Men x.RecordCount er ikke defineret før hele resultsættet er leveret fra
serveren til klienten.

I det her tilfælde taler vi 11.000+ records i Kurt's udtræk, og det vil
kræve dobbelt gennemløb for at finde det forventede antal.

Nu ved jeg ikke lige med Access, men hvis det er MS SQLServer er det
optimale at udtage en 'fast forward read-only serverside cursor' ved
læsniger.

Man kan godt lave lidt 'tricks' ved at udtage andre cursortyper - og
placeringer, men man skal passe på med større datamængder, og ikke mindst
risikoen for 'aggresive locking scheme' (især ved flerbrugersystemer).

--
Med venlig hilsen
Stig Johansen