The asp.net membership has the mechanism that it locks out a user's account if he/she tries to authenticate themselves with false password five times, by default, or within 10 minute window. The locked user can then not login.

In the MembershipUser class there is a public method UnlockUser() that you can call for any username to unlock the user, this will reset their LastLockOutdate field etc and allow the users to login using the same password.

   1: MembershipUser user = Membership.GetUser(username);

   2: user.UnlockUser();

Many of us have faced a problem where we need to compare historical records for a particular set of records to ensure that records have been saved in the correct order.

This could be for comparisons of dates or numbers or anything.  The need is to ensure that the historical records have been saved in the correct order. Using Cross joins, we can identify records that have been stored out of order for a subset of records.

Let’s say I have table in which there are three fields:

EmployeeId
Version
CreateDate

Here, EmployeeId is an integer field and is our primary ID. Version is also an integer field,considering this as a secondary ID. So, in totality EmployeeId and Version will form the Composite Key. There can be many versions of the same EmployeeId and each Version would have a corresponding CreateDate.

Our problem is to compare the CreateDate of all the versions of a particular employee on an iterative basis using a single query to ensure the CreateDate are in order based on the Version for a particular employee.

The below scripts will help you understand the problem and its solution.  I am using a new table, adding some data and then using the query to determine which records are out of order.

   1: CREATE TABLE Employees(

   2:      EmployeeID INT        NOT NULL,

   3:      Version    INT        NOT NULL,

   4:      CreateDate DATETIME   NULL,

   5: CONSTRAINT pk_Employees PRIMARY KEY CLUSTERED 

   6: (

   7:      [EmployeeID] ASC,

   8:      [Version] ASC

   9: ))

  10: GO

  11: INSERT INTO Employees VALUES(1,0,'03/10/2000')

  12: INSERT INTO Employees VALUES(1,1,'03/16/2000')

  13: INSERT INTO Employees VALUES(1,2,'03/19/2000')

  14: INSERT INTO Employees VALUES(1,3,'03/18/2000')

  15: INSERT INTO Employees VALUES(1,4,'03/17/2000')

  16: INSERT INTO Employees VALUES(2,0,'02/10/2000')

  17: INSERT INTO Employees VALUES(2,1,'02/11/2000')

  18: INSERT INTO Employees VALUES(2,2,'02/18/2000')

  19: INSERT INTO Employees VALUES(3,0,'03/25/2000')

  20: INSERT INTO Employees VALUES(3,1,'03/23/2000')

  21: INSERT INTO Employees VALUES(3,2,'03/26/2000')

  22: INSERT INTO Employees VALUES(3,3,'03/30/2000')

  23: INSERT INTO Employees VALUES(4,0,'08/19/2000')

  24: INSERT INTO Employees VALUES(4,1,'08/20/2000')

  25: INSERT INTO Employees VALUES(4,2,'08/23/2000')

  26: INSERT INTO Employees VALUES(4,3,'08/24/2000')

  27: GO

  28: SELECT *,

  29:      (SELECT 

  30:           CASE WHEN (SUM(CASE WHEN B.CreateDate<C.CreateDate THEN 0 

  31:                ELSE 1 

  32:                END))>=1 THEN 1 

  33:           ELSE 0 

  34:           END AS IsNotProper 

  35:      FROM Employees B CROSS JOIN 

  36:           Employees C

  37:      WHERE B.EmployeID=A.EmployeID 

  38:           AND C.EmployeID=A.EmployeID 

  39:           AND B.Version<>C.Version 

  40:           AND B.Version<C.Version) 

  41:      AS [OutOfOrder] 

  42: FROM Employees A 

In the output it will display all the records with a flag called OutOfOrder. If the flag is 1 that means there is a problem with the record order. Otherwise, the EmployeeID’s versions are in proper order.

In the above example you can see that EmployeeID 1 has two records that are out of order.  The 2003-03-18 record came before the 2008-03-17 record, so the query picked these up as being out of order.

So, instead of using loops and cursors to determine if there is an issue it handles everything in a single query.

Worried about fluctuations in Google PageRank may be a complete waste of time but still, the PageRank values of individual web pages on a site can give you some good idea about the importance of those pages in Google.

For example, if there are two or more pages on your site with very similar content, find the one with highest PR and then do a 301 redirect on the other pages. This is a vague example but you should get the idea.

Brandon Thomson has created a PageRank Checker service powered by the Google App Engine that lets you calculate the Google PageRank of multiple URLs in one go. You can either upload the XML sitemap file of your website or create a simple text file with a list of all page URLs and upload that to PageRank Checker.

The service can also help you find the Google PageRank of all URLs that are linked from a particular web page.

I’ll show you how you can quickly enable ViewState compression and show you the effects it has on overall ViewState size and server performance.

How do I enable Viewstate compression?

Enabling ViewState compression with the RadCompression module really couldn’t be easier. It requires no changes to your code, no changes to your markup, and not even a change to your web.config (assuming you’ve already added the required HttpModule references). The only thing you need to do is add a new Browser file to your web project (or modify your Browser file if you’re already using one). To add a new Browser file, follow these simple steps:

• Right-click on your web project, select "Add…" > "Add ASP.NET Folder…" > "App_Browsers"
• Right-click in your new App_Browsers folder, select "Add…” > "Add New Item…" > "Browser File"
• The new browser file will have some default values, feel free to delete everything and then add this code:

   1: <browsers>

   2:  <browser refID="Default">

   3:  <controlAdapters>

   4:  <adapter controlType="System.Web.UI.Page" adapterType="Telerik.Web.UI.RadHiddenFieldPageStateCompression" />

   5:  <!--Uncomment the following line to use SessionStateCompression and remove ViewState from the page-->

   6:  <!--<adapter controlType="System.Web.UI.Page" adapterType="Telerik.Web.UI.RadSessionPageStateCompression" />-->

   7:  </controlAdapters>

   8:  </browser>

   9: </browsers>

And that’s it!. Run your project at this point and you’ll discover that the RadCompression module is now automatically compressing your ViewState.

How much does the compression help?

ViewState, as you probably know, is just a serialized string of data. By default, it’s not compressed, it’s not encrypted, and it’s often a bloated piece of string data that gets passed back and forth with every request to the server.

Compressing this data is an easy way to reduce your page size and reduce the number of bytes you must send and receive from the server.

To demonstrate RadCompression’s effectiveness, I created a simple page with a RadGrid that loads data from the AdventureWorks Employees table. I bound my grid declaratively to an EntityDataSource and I slowly started increasing my Grid’s page size- from 10 records to 240 per page. As the page size grew, obviously the ViewState grew.

RadCompression Efficiency

The blue bars represent the ViewState size (in KB) with RadCompression. The green bars represent the difference in the original ViewState size (i.e. total size with no compression). And the red numbers indicate the compression “efficiency” at each step (for instance, “53%” means the compressed ViewState was 53% smaller than the original).

• As the original ViewState grew, the compression became even more “efficient” (ranging from 47% to 75% compression ratios)
• In the first two tests, there was no difference between the original and the “compressed” output – more on this in a moment
• On average, RadCompression reduced ViewState size by 61%! (omitting the “0” tests)

So why are the first two tests “0%”? RadCompression actually has a “threshold” that must be passed before compression will kick-in. For smaller ViewState sizes, it doesn’t make sense to apply compression- the overhead of the processing and compression header/footer offset the small gains in overall state size. Currently, this threshold is 8KB. If your original ViewState is smaller than 8KB, RadCompression will automatically skip over it. Bigger than that, and RadCompression will automatically work.

What is the effect on server performance?

Many people will often say, “Sure you can compress ViewState, but doesn’t that add significant processing overhead on the web server?” It is true that adding compression represents extra CPU cycles and it does have an effect on server performance. With RadCompression, though, that impact is relatively small. Internally, RadCompression uses Deflate compression to compress and decompress state, which is much faster than Gzip compression. And thanks to the optimizations of the compression APIs in .NET, the overall effect on server processing time is low.

This may be one of the easiest ways to help reduce your page size, and in turn, help improve your page performance. By simply registering the RadCompression HttpModule and adding a .browser file to your project, you can see reductions of over 70% in your ViewState size with little impact on your server performance. Clearly, as developers we should all be taking active steps to reduce our ViewState size, but if you’ve already done everything you can (or at least everything you have time for) and you want to squeeze a few more KB out of your page, RadCompression is ready and waiting for you in your Telerik toolbox.

I stumbled upon this site while browsing today, thought will share it with all.

The site gives you a solid foundation to build your project on top of, with an easy-to-use grid, sensible typography, useful plugins, and even a stylesheet for printing.

Blueprint: A CSS Framework | Spend your time innovating, not replicating