PID Event TimeStamp 1234 Login 10:00 5678 Login 10:20 1234 Logout 11:30 5678 Logout 11:40
Requires Free Membership to View
The trick here is to match up each login with its logout. Again, a scalar subquery in the SELECT clause comes to the rescue. But first, let's create and populate our table (note: this is Oracle flavored SQL):
create table ConnectionLog
( PID number(4),
Event varchar(6),
Logged date
);
insert into ConnectionLog values (1234, 'Login',
to_date('12-MAR-2002 10:00','DD-MON-YYYY HH24:MI'));
insert into ConnectionLog values (5678, 'Login',
to_date('12-MAR-2002 10:20','DD-MON-YYYY HH24:MI'));
insert into ConnectionLog values (1234, 'Logout',
to_date('12-MAR-2002 11:30','DD-MON-YYYY HH24:MI'));
insert into ConnectionLog values (5678, 'Logout',
to_date('12-MAR-2002 11:40','DD-MON-YYYY HH24:MI'));
Our scalar subquery will return the earliest logout that occurs after the login for each PID. Subtract the login from the logout and we have the duration. Here's the SQL:
select PID, ( ( select min(Logged)
from ConnectionLog
where PID = t.PID
and Logged > t.Logged )
- Logged
) * 24 * 60 as DurationInMinutes
from ConnectionLog t
where Event = 'Login';
Notice I didn't specify that Event must be 'Logout' in the subquery. This is by design. If the session doesn't logout before a subsequent login, the subquery will act as though there is an implicit logout. That is, the next event, whether it is a login or a logout, is treated as a logout for the purpose of the subquery. Here are the results of the query:PID DURATIONINMINUTES ---- ----------------- 1234 90 5678 80
For More Information
- What do you think about this answer? E-mail the edtiors at editor@searchDatabase.com with your feedback.
- The Best SQL Web Links: tips, tutorials, scripts, and more.
- Have an SQL tip to offer your fellow DBAs and developers? The best tips submitted will receive a cool prize. Submit your tip today!
- Ask your technical SQL questions -- or help out your peers by answering them -- in our live discussion forums.
- Ask the Experts yourself: Our SQL, database design, Oracle, SQL Server, DB2, metadata, object-oriented and data warehousing gurus are waiting to answer your toughest questions.
This was first published in March 2002
Join the conversationComment
Share
Comments
Results
Contribute to the conversation