Sessioner

Med på en lytter.

Jeg bruger selv SPID'et til at identificere en bruger, men når denne lukker programmet igen kan jeg ikke være 100% sikker på det registreres (ved at SPID og IP fjernes fra brugerens record).

Jeg har en TImAlive tråd der med jævne mellemrum opdaterer et tidsfelt i brugerens record så man kan se sidste livstegn.

Jeg registrerer IP-nummer så jeg kan sammenligne med det

.. og hvis en bruger får et SPID som findes i databasen kan jeg konkludere at den eksisterende er der ved en fejl.

Alt dette er konceptuelle lappeløsninger, så hvis Jens får en brugbar løsning vil det være med til at gøre mit program smukkere.

Jeg tror ikke at der er en perfekt loesning.

SQLServer understoetter LOGIN men ikke LOGOFF triggers.

Den forkromede loesning skulle vaere denne her:

http://www.jimmcleod.net/blog/index.php/2008/05/28/auditing-user-log-out-events/

men den er jo lidt kompleks.

En pragmatisk loesning var at:
1) putte signoff i en exit handler saaledes at den vil blive udfoert ved naesten alt andet end power off
2) putte login tid i den row og saa naeste gang der logges ind fra den bruger eller efter N minutter saa antages det at brugeren er vaek

Jeg ville ioevrigt aldrig slette den row, men derimod kun tilfoeje en logoff tid og saa inserte en ny row naeste gang.

arne: altså stort set sådan sm jeg gør. Har overvejet at lade programmerne snakke sammen. De har jo IP-nummeret og så kunne de via en sccketforbindelse spørge rundt.

Kan det virkelig passe at der ikke er noget der trigges når et SPID bliver ledigt? Det lyder aldeles ... træls. Hvad kunne begrundelsen for ikke at lave en sådan, være?

SQLServer har valgt ikke at have en SIGNOFF trigger. Det forlyder at Oracle har saadan en, men MS har altsaa ikke prioriteret en saadan.

Det bedste var formentligt at redesigne saaledes at behovet for at fange session slut forsvandt.

Da jeg mit projekt tænkte jeg, at når SqlServer har et SPID, så var det lige til højrebenet at bruge i forbindelse med login. Det mener jeg egentlig stadigvæk for jeg kan ikke se hvordan man kan lave en pæn løsning på anden måde. Det ville have hjulpet på min løsning om SPID var fortløbende, men perfekt er det stadig ikke. Men det er ikke mine kvaler det handler om, det er Jens'. Jeg er bare med på en lytter :-)

SPID har en 1:1 relation til database connection. Men det har vel ikke noget at goere med behovet for at goere noget naar connection forsvinder.

I mit program har det, for når brugeren opretter forbindelse til databasen, er det SPID'et der identificerer brugeren (sætter SPID ind i brugerens record (i brugertabellen)). Det betyder, at når jeg skal referere til brugeren, behøver jeg blot kalde en funktion som finder bruger_id via SPID'et. Det sparer en masse parametre i mine SP'er og fungerer fint.

Jeg har dog grublet lidt over det i nat (når man ikke kan sove så kan man ligeså godt forsøge tænke). Jeg tror jeg justerer mit program til at skulle forny sit abonnement i 1 minuts intervaller. Egentlig bare inkludere mit "ImAlive" felt (datetime) i login, der opdateres af en tråd i programmets levetid. Hvis det er over 1 minut siden at stemplet er blevet opdateret, så er der tale om fejl og man kan igen logge ind med dette login. En tanketorsk at det ikke er sådan allerede. Tak Arne.

Jeg kom pludselig i tanke om at jeg bare kan rydde op i min user session når jeg logger ind i programmet ... Så nu er mit problem løst.

Meeen i stedet for at lukke spørgsmålet vil jeg hellere dreje det over i en principiel diskution :

Jeg kunne godt tænke mig at vide om der findes en løsning i ren SQL uden brug af Jobs .. Altså noget med en Service eller en kø.

Jens B