Friday, June 15, 2012

Easy way to generate random character string for password in SQL Server


Hi Friends!

I was searching for generating random character string for password in SQL Server and goggled a lot.

I have found various stored procedures and functions to generate random character password (it was really big procedures/functions !!)  So I have given a thought and an idea strike on my mind and then I have found following, the most simplest way to generate random character string of password.

SELECT 
LEFT(UPPER(NEWID()), 2) + 
LEFT(LOWER(NEWID()), 2) + 
LEFT(UPPER(NEWID()), 2) + 
LEFT(LOWER(NEWID()), 2)

The above is very basic form to generate random character string for password. you can customize this according to your requirement (like variable password length and etc.)

Happy Programming :)

Wednesday, May 30, 2012

jQuery 1.4.x Ajax traditional option



I have a very simple jQuery code that basically sends an array of integer back to my ASP.NET MVC Controller class.

jQuery code

$.ajax({
   type: 'POST',
   url: "/MyController/MyAction",
   data: { myArray: ids }
});

My controller action:

public void MyAction (int[] myArray) {
   // do stuff here ...
}

But upon upgrading to jQuery 1.4.x, it does not work anymore. The param "myArray" in MyAction is always null.

During debugging, I found out that somehow it sent the post data as "myArray[]" instead of "myArray". 

We cannot name a parameter name with brackets in C# so simply renaming the parameter name in MyAction won't work.

After some readings, it turns out that this is a change in the jQuery 1.4 release - it changes the way it does param serialization. But, jQuery also provides a new flag in $.ajax to override the default behavior (and go back to use the old way of param serialization): the "traditional" option in 

$.ajax. So here is my revised code:

$.ajax({
   type: 'POST',
   url: "/MyController/MyAction",
   data: { myArray: ids },
   traditional: true
});

You can read more about the new param serialization here.

Thursday, March 29, 2012

How Dangerous Null values are in Sub query...


Recently I came across a strange problem while using simple sub query, everything was right but no data was returning.

DECLARE @Users TABLE (UserName VARCHAR(10))
DECLARE @ExcludeUsers TABLE (UserName Varchar(10))

INSERT INTO @Users
      SELECT 'User1' UNION SELECT 'User2'
     
INSERT INTO @ExcludeUsers
      SELECT 'User1' UNION SELECT NULL

SELECT * FROM @Users
SELECT * FROM @ExcludeUsers
SELECT * FROM @Users WHERE UserName NOT IN (SELECT UserName FROM @ExcludeUsers)

Here table1 (@Users) contains  two users
And table2  (@ExcludeUsers) contains one user and one NULL value

Now when we try to query the users that are not available in table2 (@ExcludeUsers) we find no rows due to one NULL value exists in table2 (@ExcludeUsers).

I have read on MSDN and found the reason as,

Any null values returned by subquery or expression that are compared to test_expression using IN or NOT IN return UNKNOWN. Using null values in together with IN or NOT IN can produce unexpected results.

So Any compare against NULL is always FALSE so we need to use IS NULL or IS NOT NULL.

 Happy Programming :)