I recently built an ASP.NET Application which makes intensive use of the build in ASP.NET Membership Class. I use it to store the number of new messages for a particular user and stuff like that as it’s very comfortable to set those values:
System.Web.Profile.ProfileBase pB = System.Web.Profile.ProfileBase.Create(UserName); pB["FriendApproval"] = ApprovalCount.ToString();
pB.Save();
I use the LastActivityDate Value to show members who have been around recently. The strange thing had been that every now and then members popped up on the top who actually haven’t been online at all.
That happens because the LastActivityDate Value is updated on every Profile Info retrieval and every Profile Info Update by default. To disable this behavior you have to modify two Stored Procedures:
aspnet_Profile_GetProperties
Remove this piece of code:
IF (@@ROWCOUNT > 0)
BEGIN
UPDATE dbo.aspnet_Users
SET LastActivityDate=@CurrentTimeUtc
WHERE UserId = @UserId
END
aspnet_Profile_SetProperties
Remove or comment out this piece of code:
UPDATE dbo.aspnet_Users
SET LastActivityDate=@CurrentTimeUtc
WHERE UserId = @UserId
That’s it! Of course you have to take care of updating the LastActivityDate yourself now, I recommend adding a User Control to the MasterPage, put the Stored Procedure for Updating LastActivityDate (write one) in its codebehind and cache the control for about 5 Minutes, your server will thank you later.
4 comments ↓
cache the control for about 5 Minutes? If you cache the UC then how will this control run for all users to update their LastActivityDate? Wouldn’t the SPROC only run for the first user that hit the page after the cache expired?
If you put up the regular caching via the .aspx site it’s being cached per user, not for the whole application..
This was very helpful. It took me a while to figure out that I needed to update the user table using UTC format so it would read correctly from the member object. Im using a session variable to hold the last updated datetime and comparing it in the form_load of the master page. Thanks for the post.
This looks fine for MS SQL, but for Oracle it’s not quite as straightforward because the Oracle stored procs are “wrapped”/”encrypted” so they cannot be editted.
Leave a Comment