Keep separate passwords: The lesson from the hacking in the news.

There is a lesson here from the hacking reports we are seeing flying fast and furious.

You must strongly consider not using the same password more than once, especially on "important sites" like your banks, your schools, Facebook, Twitter (places that are your identity)

Use as long a password as you can and do not put any identifiable words, numbers, names or birthdays. If you must, write them down (despite what experts say) because it is more important you have separate, unique passwords for these important sites.

If one gets stolen (it seems corporate security measures, are at an all time low... worse than we ever imagined), and you use it for your bank as well... guess what happens next?

If you choose to write these down, protect the piece of paper like you would your credit card or SSN card. But it is more important right now that you have separate passwords than to "not write them down".

What we are discovering is that best practices for storing credentials are not even close to being followed. The Gawker hack may have showed way too many users are using "password" for their password, but it also shows that web programmers are NOT PROTECTING YOU.

The Sony hack shows that, even if you just use a Playstation 3, they still have your create a user name and password and you might be putting in your credit card information so you can make purchases quickly. That data is at risk if you reuse passwords on another site that is compromised.

The hacking at Sony started with Sony shutting down it's Playstation Network because they discovered they left the door open to copying game content. When the extent of just how lax was Sony was in their security practices, hackers pounced. They're going after every site Sony has any connection to in every country, looking for anything. And that's when the password stealing started heating up.

A web site should be able to protect your password by NEVER STORING IT. I know that might sound weird, but it is 100% true. There are much much safer ways to authenticate a user without actually knowing the true password. I won't get into the gory technical details, but just be warned that if you read a story about a hack where passwords were recovered, rest assured this is a company that does not deserve your business. They are not even following the best procedures of 1995, much less 2011.

The scary thing here is I think this is the tip of the iceberg. Now that we know that passwords are being kept in plaintext or in hashes that are not salted, hackers are more curious to see just how many web sites out there are not protecting you. You have to protect yourself.

If your bank is compromised and your password exposed, you can at least know that hackers can't use that information, by itself, to go log into all of your other banks, Facebook, Twitter, and web based email, because you don't use the same password twice.

To be perfectly honest with you, I do have to get going. I have to go change one or two passwords I've been neglecting.

With SQL Server 2008 R2, using the LocalReport class throws The report definition is not valid. The Report definition has an invalid target namespace"

I needed SQL Server 2008 R2 to get a a few features. One of them was having the ability to define tabs for Excel rendering in reports. Another was the shared dataset features and shared report features.

Anyways, I wanted to try using LocalReport to render an Excel workbook from a report without actually needing SSRS installed and the report deployed and all that. It's a solution a lot of developers seem to use.

Here's the issue.

The ReportViewer control was not updated to handle rdl or rdlc files made with Report Builder 3.0. I don't user Report Builder (I use BIDS) but as far as I can tell, if you've set bids Target Deployment Server to R2 (which I have), you create rdl files that match the new schema.

That's what ReportViewer is complaining about. There seems to be no fix planned. It's a "wait for Denali" thing, as frustrating as that is.

So my workaround was to go ahead and deploy and configure to a real SSRS server, instantiate a ReportViewer control on my own in code set to Remote Processing and go get the form. It's working so far.

I know that's not a good workaround for everyone. I'm not sure how the licensing works, but I suppose it might be okay to use the cheaper SQL Developer Edition and ship RDL files you make with the free ReportViewer controls.

Quarter Start and End Dates Table in SQL Server 2008 with DATEDIFF and DATEADD

I was asked if I could populate a table with the next 40 quarter end dates. It's always best to populate calendar tables than to try to write SQL code to figure it out on the fly or in a view. That way lies madness.

Without further ado, this populated the next 100 dates.

/*
* *** Create Simple Quarters Table ***
* Just hitting execute will create a table with Quarter Start and End dates
* and a row number to order them by or do joins with later.
*/

-- If you want more than 100 future quarters, watch out for max recursion. Scroll down and bump that number accordingly.

-- Uncomment this after you've made the Quarters table
DROP TABLE [Quarters]

DECLARE @todaysDate [datetime];
DECLARE @todaysQtrNum int;
DECLARE @qtrCalc int

SET @todaysDate = GETDATE(); -- Or set the date yourself here
SET @todaysQtrNum = DATEDIFF(q, 0, @todaysDate);
SET @qtrCalc = 99; -- How many future quarters are we calculating (1 more will be added for current)

WITH Numbers(n)
AS
(
SELECT 0 AS n
UNION ALL
SELECT (n + 1) AS n
FROM Numbers
WHERE
n < @qtrCalc
)

SELECT n as QtrNumber,
--@todaysDate as Today,
--@todaysqtrnum as TodaysQtrNumber,
DATEADD(q, @todaysQtrNum+n, 0) AS QuarterStart,
DATEADD(d, -1, DATEADD(q, @todaysQtrNum+n+1, 0)) AS QuarterEnd
INTO [Quarters]
from Numbers
--OPTION(MAXRECURSION 100) -- defaults 100

-- See your creation
SELECT * FROM [Quarters]

P.S. Certainly this could be incorporated into a larger Calendar table. It just wasn't needed here and sometimes you might want the specialization.

P.P.S. I found the numbers query technique using recursion on Code.I.net blog. It won't get you past around 10000 for quarters and AFAIK recursion is limited to 32767 anyways. But it worked and sometimes that's all you need (especially when it's one time use).