Varukorg: Session och recordset?

En tredimensionell array tror jag inte du kan skapa med ASP... men där kan jag ha fel. Jag har aldrig sett något skrivet om det. Men så har jag inte heller läst allt som står skrivet om ASP! :-)

Ett recordset är att koda från databasen. Att "permanent" spara data kan du bland annat göra i något som kallas application -variabler. De fungerar som session, fast för hela servern.

session("mittNamn") <--- ny för varje användare, dör vid session.abandon.
application("minServerNamn") <--- dör "aldrig", påtvingad död = starta om servern alternativt ladda upp en ny version av filen global.asa (Nytt senast ändrad-datum, räcker med ett mellanslag eller retur.)

***
Sen finns det en funktion som heter dictionary som du kan söka på men också läsa mer om till exempel här:
http://www.w3schools.com/asp/asp_ref_dictionary.asp

Jag använde det en gång på en sajt för snart sju år sedan. Jag tog nyligen bort det för jag fattade inte hur det fungerade... men det kanske var dumt!? Det fungerade mycket bra nämligen.

Jag överväger att bli kompis med dictionary igen! :-)

Ok... Tack för informationen men jag är med så lång som hur session och application fungerar..

Det jag funderadde mest är hur man använder recordset. har för mig att jag sett exempel n¨gonstans där dom kallad e det för bindningslöst recordset eller liknande. Kom tyvärr inte så längt med google på det..

jag är nog ute och cyklar när jag skriver tre dimensionell array..
jag menade att jag delade upp arrayen med kolonn och semikolon. alltså blir ju som en tabell
ex

1:1:100;2:1:50
varje artikel avdelas med semikolon så första siffran är id, andra är antal ocg tredje är pris; och sen nästa artikel.. Känns inte så effektivt.. Bästa hade ju varit om man kunnat skapa en tabell med ett recordset och sedan arbetat med det istället...

OK, jag fattar! Du tänker rätt men det blir fel!

Det är [någonting]-lös dns koppling du söker... det är riktigt.

Du skapar en korkad array, skulle jag namnge den varianten du skriver! jag har aldrig sett en sån variant och vad kan det vara bra för!? Vet inte... Säkert i något sammanhang...(???)

För att inte förklara saker du redan vet, vad av detta förstår du inte?

1. öppna databasen

2. SQL = "Select intID, strName, dteCreated FROM [users];"

3. set mySQL = Conn.Execute(SQL)

4. IF NOT mySQL.EOF THEN session("listaAllaAnvändare") = mySQL.GetRows()

5. stäng databasen.

***

längre ner på sidan eller i ett annat sammanhang:

IF IsArray(session("listaAllaAnvändare") ) = TRUE THEN
  myRow = session("listaAllaAnvändare")

  ' ## LOOPA GENOM ALLA ANVÄNDARE:
  FOR j = 0 TO UBound(myRow,2)
    response.write "ID: " & myRow(0,j) & " -- namn = " & myRow(1,j) & "<br>"
  NEXT

END IF

Detta är en TVÅDIMENSIONELL array:

rad 0:  ID | namn | datum
rad 1:  ID | namn | datum
rad 2:  ID | namn | datum

rad 0:  23 | Tage | 2009-11-22
rad 1:  24 | En | 2009-11-22
rad 2:  25 | Taxi | 2009-11-22

definition av position:
rad 0:  0,0 | 0,1 | 0,2
rad 1:  1,0 | 1,1 | 1,2
rad 2:  2,0 | 2,1 | 2,2

Detta ger antalet poster i x-led, i sidled:
response.write UBound(myRow,1)

- detta är rätt onödigt att veta, med kod. du vet redan, SELECT ...

Detta ger antalet poster i y-led, i höjdled:
response.write UBound(myRow,2)

- detta vet du aldrig, detta är ANTALET poster.

Skriv inte:
SQL = "SELECT * FROM [users]"

Ta dig tid att skriva:
SQL = "Select intID, strName, dteCreated FROM [users];"

***
1. Du vet EXAKT vad din fråga består av.
2. Du har inte arrayer och variabler som är större än absolut nödvändigt.
3. [users] kanske innehåller 20-30 kolumner, men fråga bara efter dom du använder!

OK... fattar du detta eller är det något som är otydligt!?

Är nog med dig till 100 %. Men tror kanske att jag var lite otydligt...
Jättetack för att du förklarar så utförligt..

Jag arbetar inte mot en databas alls.. Utan vill ha en varukorg på klient nivå (session) jag sparar varukorgen i databasen först när man bekräftar beställningen..

jag hade helt fått för mig att man kan skapa ett tomt recordset utan att ens koppla mot databasen, ungefär som att skapa en "virtuel" databas eller tabell och spara i session variabeln.. Precis som du visade fast utan databaskopplingen??

Kanske är jag som snurrar nu??

Tusen tack iaf

jag hittade faktiskt en lösning, eller iaf ett exempel som tar upp koplingslöst recordset. Tror detta kan vara riktigt bra då det inte blir så många skrivningar mot databasen hela tiden..
http://www.gladh.nu/asphelp/svar7.html

Nej... skippa det. Kör mot databas i stället. Det är bättre för dig.

Det blir inte särskilt mycket db-trafik och det är bara drygt och dumsnålt att inte köra databas.

***

response.write session.sessionID

Vad är det för saker du har i din korg? Ska man kunna köpa flera saker på en gång, eller bra en av varje?

Använd sessionID för att skilja besökare från varandra. Det är skitlätt och du fattar vad du gör, även i en ospecificerad framtid. Andra fattar vad du gör, så du kan få hjälp.

Du måste kunna dela med dig av din kod! :-)
Tro det eller ej, men det är ingen nackdel...!!

Använd session ID för att veta att "din" besökare fortfarande är "din" besökare! Din besökare kan ju surfa runt på webbplatsen i flera timmar, och är det samma ID är det samma besökare. Är det ett annat ID, blir korgen tom. En session dör på 20 minuter, om du inte anger annat.

Sen kan du tydligt följa hur många avslut det blir, om du gör ett gränssnitt för det. Varje "köp" sparas i db och med ett unikt sessions ID, som givetvis är samma för en besökare...

Du får ju garanterat aldrig två besökare med samma ID. OK, det kanske du får under extrema omständigheter... men ... den dagen den sorgen! :-)

Skippa kopplingslöst recordset. That's my vote!

preben skrev:

Du får ju garanterat aldrig två besökare med samma ID. OK, det kanske du får under extrema omständigheter... men ... den dagen den sorgen! :-)

Det stämmer inte helt, Session.SessionID är inte garanterat unik, speciellt inte mellan omstarter av IIS. Jag skulle verkligen inte rekommendera att använda Session.SessionID som en persistent pekare på en användares privata data, utan att verifiera identiteten på en annan nivå också. Visst, chansen är liten, men jag hade inte använt den. Generera en GUID istället och sätt i en cookie på klienten istället. Skapa GUID: http://www.aspsidan.se/default.asp?page=readarticle&artId=505.

Vidare, precis som så många andra visa människor har sagt; lagra aldrig objekt i Session eller Application. Aldrig. Speciellt inte ADODB.Recordset's. Det är att be om trubbel.

Istället, gör som preben sagt, och återigen många andra visa människor; lagra kundkorgen i databasen och bind på GUID mot en cookie. Om du har gamla kundkorgar som inte används i en databas tar det bara (disk)utrymme, om du har kundkorgsobjekt i Session eller Application som ingen har koll på så slösar du resurser = minnesläcka.

För det första är sessionID rätt lång. Hur lång vet jag inte... Sen är det så att alla webbplatser på hela servern delar på samma sessionID-räkneverk. Det normala är att man använder en webbserver på ett webbhotell och inte själv kan starta om servern.

Men visst! Har man en egen server med typ fem användare om dagen som man startar om dagligen, då finns stor risk att samma nummer kommer om och om igen!

Nu är ju inte den typen av konfigurering det mest vanliga, men visst. Den förekommer säkert!

civilpolisen skrev:

För det första är sessionID rätt lång. Hur lång vet jag inte... Sen är det så att alla webbplatser på hela servern delar på samma sessionID-räkneverk. Det normala är att man använder en webbserver på ett webbhotell och inte själv kan starta om servern.

Men visst! Har man en egen server med typ fem användare om dagen som man startar om dagligen, då finns stor risk att samma nummer kommer om och om igen!

Nu är ju inte den typen av konfigurering det mest vanliga, men visst. Den förekommer säkert!

Som sagt, risken är inte stor. Men risken för problem ökar om man lagrar numret i t.ex. en databas, där det blir persistent och sedan enbart jämför på det ID't.