Monday, August 14, 2017

Honolulu Hands-on Training: Introduction to Structured Query Language (SQL)

The next session will be starting October 12, 2017. Register early.

Explore funding opportunity here:

Saturday, August 12, 2017

Encrypted email passwords in SQL Server

You could keep your email addresses and passwords in SQL Server database table. You could get a free copy of your SQL Server from a Microsoft download site.

While the email addresses can be kept un-encrypted, you may want to keep your passwords in an encrypted column of a table. If want to keep everything encrypted you can do it also.

With this table set up correctly you may need to remember just one phrase which can be of your choosing.

Here are steps to create such a table:

1. Create a table in one of your existing databases. I am creating this table in a database called 'Aloha' which I use for teaching.

Here is the statement to create the table:

USE Aloha
Create Table Encrpt(
emailID int Primary Key not null,
emailAdd nvarchar(25) null,
emailPswd varbinary(250) null

This creates the table ENCRPT.

The email password (emailPswd) is stored in a special column(varbinary data type) as shown above.

Now keep a list of emails and the passwords ready to populate the table.

Populate the table you created by inserting values using the following code:

INSERT INTO ENCRPT(emailID, EmailAdd, emailPswd)
values (1, '', EncryptByPassPhrase('Happy birthday to you','xyzpo')),
(2, '',EncryptByPassPhrase('Happy birthday to you ','ZZZ12$' )),
(3, '',EncryptByPassPhrase('Happy birthday to you','$$$11X' ))

I have inserted only three values but you could add more. While the email addresses shown are my real addresses, the passwords are not.

Now when you run a SELECT statement to display all the columns, this is what you see.

Here is a screen shot of all code:

I have used the same PassPhrase for all data, you could have different on, the onus of remembering phrases is on you.

The fourth row was filled using a different PassPhrase ('Happy Anniversary).
Read more here:

Thursday, August 10, 2017

SQL Server and two-digit cutoff

Remember the millenium bug fiasco. It happenned in Year 2000.
This is what chronicled in Wikipedia:

"The Year 2000 problem is also known as the Y2K problem, the Millennium bug, the Y2K bug, or Y2K. Problems resulted because people, including programmers, reduced the four-digit year to two digits. This made the year 2000 indistinguishable from 1900"

Now we have a better interpretation for people using two digit years as far as SQL Server is concerned.

The default time span for SQL Server is 1950-2049.

Two-digit year 49 is 2049, but two digit year 50 is back to 1950.

Probably you will start seeing it in your credit cards (may be?)

You may configure it in SQL Server 2017 using,

Exec Sp_Configure 'two digit year cutoff', 2038

In SQL Server 2012 Express it is enabled by default:

Read more here: Protection Status