server.transfer vil ikke

Server.Transfer kan ikke tage queryparametre, da det ikke er et nyt request, men mere at sidestille med en parameterløs sub-rutine.

Du kan dog i den side du kalder med Server.Transfer sagtens tilgå både request.querystring, request.form osv. fra det oprindelige kald. Det betyder at hvis din hovedside kaldes med en query-parameter, så kan vare.asp også aflæse denne igennem request (præcis som du ville have gjort, hvis koden fra vare.asp havde ligget i hovedsiden.

Hvis du vil overføre parametre til en asp-side der kaldes med server.transfer, kan du f.eks. benytte session eller application objekterne til at gemme værdierne midlertidigt...

OK,
tak for hjælpen.
Jeg prøver med session.
Det som jeg er ved at eksperimenterer med er url-adresser som er mere brugervenlige og til søgemaskinerne.
Kan du fortælle mig hvad der vil bruge flest recurser på serveren session eller application?

Og kan du give et eksempel med application, for den har jeg aldrig brugt før.

Søgemaskinevenlige adresser og ASP er generelt set en dårlig kombination, med mindre du vil ud i noget avanceret strukturering af dine filer eller installation af URL-rewriting komponenter på serveren (typisk ikke noget man lige får lov til ved en standard ISP :)).

Application-objektet fungerer i princippet på samme måde som session når det drejer sig om at lægger data i det. Du skal dog nok ikke satse på at bruge det til alt mulig, da det er et objekt der er adgang til fra alle brugere på sitet og det gør dermed også sitet mere sårbart overfor låsning, hvis du bruger det forkert - låsning som kan skade sitets performance og dermed skalerbarhed.

Det er min overbevisning, at session bruger mere plads end application, da det stille mange flere features til rådighed i forhold til styring af brugeroplysninger og fordi det er beregnet til at integrere med den enkelte brugers forespørgsler til serveren. Alle disse ting er noget du selv skal styre, hvis du vælger at benytte application i stedet... men det er en noget overfladisk forklaring på application- og session-objekterne - der er meget mere i dem end det og det er noget man nok skal læse en del artikler om og have noget praktisk erfaring med før det helt bliver klart hvilke konsekvenser brugen af dem har.

Application kan f.eks. bruges således:


Skal jeg så hente denne værdi kan jeg aflæse den således:


Hvis "noegle" ikke findes i Application's Content-liste, så returneres der Empty, hvilket kan kontrolleres med


Som du kan se er brugen af Application ikke umiddelbart så forskellig fra brugen af Session-objektet, men der er som sagt mange andre ting Session kan give dig som Application ikke kan (ud over skalerbarhedsproblemer :)).

Jeg tror det er bedst at investerer i et komponent.
Har kigget på den her: http://www.helicontech.com/isapi_rewrite/

Siden har godt med trafik og den er stigende så jeg kan ligeså godt belaste serveren så lidt som muligt.
Det er en dedikeret server, som kører denne ene side og en mailserver. Mailserveren har kun ganske få brugere.

Eller kan jeg opgradere IIS 6.0 til 7.0 Hvor der er et "URL Rewrite Module"

Jeg er ikke afklaret med hvad IIS 7 tilbyder i forhold til url rewriting i ASP Classic, så om det er en løsning kan jeg ikke be- eller afkræfte. Jeg har først for nylig stiftet bekendtskab med IIS 7 og det indbyggede fejlrapporteringsmodul, hvilket har været en stor hjælp allerede! Men det er jo en anden historie :)

Jeg har aldrig prøvet at benytte tredieparts url rewriting-komponenter, så der kan jeg heller ikke rigtig give dig nogle råd.

OK,
Jeg har lavet en function som bygger en html-fil for hver vare,
så de kommer til at hedde noget i stil med roed-tanktop-14232.asp
Det giver også en mindre belastning på serveren.
Skriv et svar hvis du vil have points.

OK, men du bør nok kalde dem noget med .htm til efternavn, for ellers bliver ASP-maskineriet fyret op hver gang en side forespørges og hvis siderne i øvrigt er statiske, så er der jo ingen grund til dette (jf. din egen kommentar om at serveren bliver mindre belastet).

Siderne viser nogle varer (tøj) og har ikke brug for .asp før de klikke på knappen "Læg i kurven"
Så de bliver til .asp-sider uden forbindelse til databasen osv.
før at en bruger klikke på knappen.

Dvs. du rent faktisk godt kan lave dem som .htm sider i stedet og så bare lade linket til "læg i kurv" være til en ASP-side der redirecter til samme .htm side som kaldet til ASP-siden kom fra (Request.ServerVariables("HTTP_REFERER") såvidr jeg husker).

På den måde sparer du som nævnt helt at ASP-fortolkeren skal startes, når siderne vises og bruger den KUN til de ting som er relevante at starte ASP op for... om det så lader sig gøre i praksis er jo interessant :-)

Hvis du har brug fro noget dynamik på siden, kan du jo altid lave noget AJAX på de områder der skal være variable (jeg forestiller mig at kurven nok skal være sådan en fætter).