Exploring SQL Server 2016 Always Encrypted – Part 4 – Encrypting Existing Data

Monday Feb 1st 2016 by Greg Larsen
Share:

Greg Larsen explores the different ways that you can encrypt your existing confidential data using Always Encrypted Columns in SQL Server 2016.

As with most new technology it is not only intended for new development, but it is also targeted at fixing existing issues with current applications.  This is also true with the new SQL Server Always Encrypted feature.  In my “Exploring SQL Server 2016 Always Encrypted” series so far I’ve only shown how to create new Always Encrypted data using .Net code that performs an INSERT statement.  In this article I will be exploring the different ways that you can encrypt your existing confidential data using Always Encrypted Columns.

Sample Data

In order to show you how to convert an existing table that doesn’t contain Always Encrypted columns, to a table that does contain some Always Encrypted columns I will use two different machines.  One machine will be named SERVER1, and the other machine will be named CLIENT1.  The first machine, named SERVER1, is the machine that contains the actual data that needs to be encrypted. The other machine I will be using is a client machine named CLIENT1.  On CLIENT1, I’ve install just SQL Server Management Studio (SSMS) for SQL Server 2016.  I will use the CLIENT1 machine to generate the encryption keys and perform the actual encryption since it will be the only machine that has access to the column master key (CMK).

In order to show you how to encrypt existing data I will first create and populate a table that contains unencrypted data.  I will do that by running the code below on my SQL Server 2016 instance, which resides on my machine SERVER1:

CREATE DATABASE Demo_Encrypt_Existing;
GO
USE Demo_Encrypt_Existing;
GO
CREATE TABLE MyConfidentialData (
   ConfidentialId int,
   FirstName nvarchar(45),
   LastName nvarchar(45),
   SSN nvarchar(11),
   DriverLicenseNumber nvarchar(20)
);
GO
INSERT INTO MyConfidentialData VALUES
   (1,'Marty','Doe','555-66-7777','DOEJ1028AZ0123'),
   (2,'Sue','Jones','123-55-7890','JONS1121XB4567'),  
   (3,'David','Smith','984-98-9843','SMID0429QA8909'),
   (4,'Randy','Johnson','251-87-9736','JOHR0714PR8765'),
   (5,'Doris','Hoffman','666-01-1235','HOFD1202TB4321');
GO
 

By reviewing this code you can see that I first create a database named Demo_Encrypted_Existing and then created and populated a table named MyConfidentialData with five different records that contain clear text data for my two confidential columns SSN and DriverLicenseNumber.

Additionally I need to create a SQL Server authenticated user named AppAdmin on Server1.  This will be the user that is used by the CLIENT1 machine to perform some of the setup work and actual encryption of the existing data.   To create this user I run the following scripts:

USE [master]
GO
CREATE LOGIN [AppAdmin] WITH PASSWORD='AppAdm1n', DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO
ALTER SERVER ROLE [sysadmin] ADD MEMBER [AppAdmin]
GO

Now that our test data and our Server1 instance is set up correctly I can continue and show you different examples of how to encrypt existing data with Always Encrypted.

Encrypting Existing SQL Server Data Using .Net Code

In this example I have developing some .Net code that reads the unencrypted data from MyConfidentialData table, and then will write it to temporary table.  While writing to the temporary table the SSN and DriverLicenseNumber columns will be encrypted.   Once the data is encrypted I will rename the original table MyConfidentialData to MyConfidentialDataOriginal, and then rename my temporary table that contains the newly encrypted data to MyConfidentialData.

Prior to creating my temporary table that will hold the encrypted data, I need set up the CMK and CEK in my Demo_Encrypting_Existing database on SERVER1.  To do that I go through the following steps.

Step 1: Create Certificate Part4_Demo1 on CLIENT1

To create the certificate I run the following command at a command prompt on my CLIENT1 machine:

makecert.exe -n "CN=Part4_Demo1" -pe -sr
LocalMachine -r -eku 1.3.6.1.5.5.8.2.2,1.3.6.1.4.1.311.10.3.11 -ss my -sky
exchange -sp "Microsoft Strong Cryptographic Provider" -sy 1 -len
2048 -a sha256

This command creates a certificate named “Part4_Demo1” on my CLIENT1 machine.   Remember, I only want my certificate to be available to my .Net application.  Since my .Net application will be running on CLIENT1, is why I create my certificate on this machine.  

Step 2: Create Column Master Key (CMK) on SERVER1

Once my certificate to encrypt and decrypt my confidential data has been set up on my CLIENT1, I need to create a CMK on SERVER1 that points to the cert I create on CLIENT1.  I create the CMK by running the following TSQL script on SERVER1:

USE [Demo_Encrypt_Existing]
CREATE COLUMN MASTER KEY [Part4_Demo1]
WITH
(
       KEY_STORE_PROVIDER_NAME = N'MSSQL_CERTIFICATE_STORE',
       KEY_PATH = N'LocalMachine/My/558DA1820E61EF0C5CAF9ED04306B49B8FDB932B'
)
 

I generated this script using SSMS running on my CLIENT1 machine.  To create this script I used the “New Column Master Key” dialog under the “Always Encrypted Keys/Column Master Keys” item under the “Security” item in database Demo_Encrypt_Existing” database.   By running this command I am telling SERVER1 where the certificate is stored on CLIENT1 machine.

Step 3: Create Column Encryption Key (CEK) on SERVER1

Now that I have my CMK defined I need to define my CEK on SERVER1.  To do that I first need to generate the script below using the New Encryption Key Dialog in SSMS on my CLIENT1 machine.  When I run through that dialog I generate the following script:

USE [Demo_Encrypt_Existing]
CREATE COLUMN ENCRYPTION KEY [Part4_Demo1]
WITH VALUES
(
       COLUMN_MASTER_KEY = [Part4_Demo1],
       ALGORITHM = 'RSA_OAEP',
       ENCRYPTED_VALUE = 
0x01700000016C006F00630061006C006D0061006300680069006E0065002F006D0079002F0035003500380064006100310038003200300065003600310065006600300063003500630061006600
390065006400300034003300300036006200340039006200380066006400620039003300320062009B0D1BDDD4B8B612E2BE99F6181A8461E99FA9FE0E707BDDB0DE306BB79CA3909D8F908D2E93
110D364A3509DDC1B49D82509EBE437EA22AB20BDBEE60EEE7112E7D5B4B33E6FA23957C0F506D709333B46ABD250D572795D958670C7EDE072C931EC6A9481F9DF0889BB64512AD797B4458DCC1
1F17BCF3841619DDBA3EEE83BF21E08DF46E6F1B999E471B8E8B5247B30B803F5B79197F0283636E811B080467F37435FF80DEA16306DC1E364BEAE0140CC82161517A0975DC23678B2A41BDBB67
5B77A9E690DFDB2DB4BB3AA1921AA0F910ACA4CA401D1ED2F0799D2DEBF3A4AEFE9744CA84F33B17A265EF7CACFA48D6E5304C8833F512069727B2D97E4B5DD196EC6CD199A099B99B304050E7BC
9F161FD94133E60FBED38AD7011C02D7D8D2B0271A75A468D68360E5E9A0846ACB64FA11DF3753FDE557B06E4A0026CFEC6685C81818E397F4BE0765BC7BB158EA9673EDF46F9EC9FC0E58115210
ADCF2FD171E8CA847C4BF39141D20984D34963329FBB0862EF54215D3E21B0427F67299DF4C01C2799C47850AB331450C5FF00EBED7E4F16C44F7EE4B7F7E663E040BFAE6C7865AE45AE88946C4B
4C6835A5AF8B28FEE4FCBD5866165CBA0211BA45F7DE8EC9E48EAEECC5A7B2D7B49F7A5C74130F82E678CFC339445B52E45A9BE5F4B2EE718781A27345C1C6920CEB3862DD41C7138363652C2257
6DD9F8F2FA81
)
 

Once I have this script I then run in on SERVER1 to define the CEK.

By performing these 3 steps I have my CMK and CEK all set up and ready for me to create a table that contains Always Encrypted Columns on SERVER1.  To create that table I execute the following CREATE table statement:

USE [Demo_Encrypt_Existing]
GO
CREATE TABLE [dbo].[MyConfidentialDataTemp](
       [ConfidentialId] [int] ,
       [FirstName] [nvarchar](45),
       [LastName] [nvarchar](45),
       [SSN] [nvarchar](11) COLLATE Latin1_General_BIN2 ENCRYPTED WITH 
    (
       ENCRYPTION_TYPE = Deterministic, 
       ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256', 
       COLUMN_ENCRYPTION_KEY = Part4_Demo1
    ),
       [DriverLicenseNumber] [nvarchar](20) COLLATE Latin1_General_BIN2 ENCRYPTED WITH 
    (
       ENCRYPTION_TYPE = RANDOMIZED, 
       ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256', 
       COLUMN_ENCRYPTION_KEY = Part4_Demo1
    )
) ON [PRIMARY]

Now I’m ready to execute my .Net code to encrypt my data.  My .Net code reads the unencrypted data in MyConfidentialData table and writes to a temporary table named MyConfidentialDataTemp.  You can find my C Sharp code that migrates my data in the section labeled “Code to Encrypt Data in MyConfidentialdata table” at the end of this article.    

Once I have executed this .Net code I can validate that the data in table MyConfidentialDataTemp table got encrypted.  I can perform that verification by running the following SELECT statement:

SELECT TOP 1 SSN, DriverLicenseNumber FROM MyConfidentialDataTemp;

When I run this code I get the following output:

SSN                                                                                                                                                                  
-------------------------------------------------------------------------------------------------------------------------------------------------------------------- 
0x015745EF4B66A8B95C565D775CC01D7CAC0FAE10CBEE43DA05142A1AB1553995F96C72D4A3B1583AD4E3FC88D4CF862FD9E33B5EE7D6BC6FD2D8919A38BAF097E7003A22BA0259F2BA08FAD20525EC790F 
DriverLicenseNumber
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
0x01C2084F57898B773140FDBBCC969DDBE45989D78A55804A87DB33075A322802B69BA5A6AF0D6272EBE212C834F717262607A2A3ADB9F36BDE7842E5D81895267EA3EEB071D16D6C0A360A346175BFD1DB

Note: Output reformatted for ease of reading

Here you can see my temporary table does contain encrypted data. The last thing I need to do is to swap my table names around by running the following TSQL Code:

sp_rename MyConfidentialData, MyConfidentialDataOriginal;
sp_rename MyConfidentialDataTemp, MyConfidentialData;

As you can see it isn’t all that difficult to encrypt existing data using this method. 

Encrypting Existing SQL Server Data using Import/Export Wizard

For the next example I’m going to use the Import/Export Wizard to encrypt my unencrypted confidential data.   In order to have the Import/Export wizard encrypt the data you have a CMK and CEK setup in the target database.  Since I’m going to use the same database as I did in the prior example these keys are already set up.  If I was using a new database then I could follow the same procedures I did in the prior section to set up the CMK and CEK.  Once those key are set up it is as simple as going through the wizard to encrypt the data. 

Since I’m going to use the same database as I used in the prior section my unencrypted confidential data now resides in a table name MyConfidentialDataOriginal.  I’m going to move the data from this table to a table named MyConfidentialDataTemp2 using the wizard.  Since my CMK and CEK are already set up in my database the only other prior encryption step I need to take is to create the MyConfidentialDataTemp2 target table for the import/export process using the following script:

USE [Demo_Encrypt_Existing]
GO
CREATE TABLE [dbo].[MyConfidentialDataTemp2](
       [ConfidentialId] [int] ,
       [FirstName] [nvarchar](45),
       [LastName] [nvarchar](45),
       [SSN] [nvarchar](11) COLLATE Latin1_General_BIN2 ENCRYPTED WITH 
    (
       ENCRYPTION_TYPE = Deterministic, 
       ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256', 
       COLUMN_ENCRYPTION_KEY = Part4_Demo1
    ),
       [DriverLicenseNumber] [nvarchar](20) COLLATE Latin1_General_BIN2 ENCRYPTED WITH 
    (
       ENCRYPTION_TYPE = RANDOMIZED, 
       ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256', 
       COLUMN_ENCRYPTION_KEY = Part4_Demo1
    )
) ON [PRIMARY]

Now that my target table is set up, it is just a matter of running through the Import/Export wizard to migrate the data.

To get started in migrating my data using the wizard, I bring up SSMS on my CLIENT1 machine.  When I start SSMS I connect to SERVER1.  Once connected I right click on the Demo_Encrypt_Existing database, hover over the Tasks Item and then select the “Import data” item as shown below:

Import Data
Import Data

When I do this the following window is displayed:

Welcome to SQL Server Import and Export Wizard
Welcome to SQL Server Import and Export Wizard

On this window I just click on the “Next>” button.  When I do this the following “Choose a Data Source” window is displayed.  On this window I pick the following options to define my data source:

Choose a Data Source
Choose a Data Source

On this page I identified where the source data is that needs to be imported.  Note how I’m using the AppAdmin user to connect to the source data in my Demo_Encrypt_Existing database.  The data will be encrypted using the rights associated with the AppAdmin user.   When I click the “Next>” button the following “Choose a Destination” Window is displayed:

Choose a Destination
Choose a Destination

On this window I select the “.Net Framework Data Provider for SQLServer” for the destination, make sure the “Column Encryption Setting” is set to “Enabled”, and then set the UserID to AppAdmin, and enter the AppAdmin password in the Password item as shown below.

Select a Destination
Select a Destination

Once I’ve completed this window as shown above I click on the “Next>” button.  This brings up the following window:

Specify Table Copy of Query
Specify Table Copy of Query

On this window, I just take the defaults and click on the “Next>” button.  Doing this brings up the following window, where I select my source and destination table:

Select Source Tables and Views
Select Source Tables and Views

Once I’ve selected my source and destination tables I click on the “Next>” button, which brings up the following window:

Save and Run Package
Save and Run Package

On this window I just click on the “Finish>>|” button.  When I do that the following window is displayed:

Complete the Wizard
Complete the Wizard

Here I review the details of my migration and then click on the “Finish” button.  Which brings up this window:

The Execution was Successful
The Execution was Successful

As you can see my migration was successful and it migrated five rows.  I verified my data was encrypted by running a SELECT statement against the table MyConfidentialDataTemp2 and then checking to make sure the SSN and DriverLicenseNumber columns are encrypted.

Now that I have verified my data is encrypted it is a simple matter of executing a couple of RENAME statements like I did in the prior section to finish the migration.

For more information about using the Input/Export wizard you can refer to the following article:

http://blogs.msdn.com/b/sqlsecurity/archive/2015/07/28/encrypting-existing-data-with-always-encrypted.aspx

Encrypting Existing SQL Server Data using the Always Encrypted Wizard

For my last method I will use the Always Encrypted Wizard.   I will be running the Always Encrypted Wizard on my CLIENT1 machine, and then pointing to my SERVER1 machine to encrypt the table name MyConfidential.  Since I have already encrypted this table I’m going to first drop the database where this table resides by running the following command:

DROP DATABASE Demo_Encrypt_Existing;

Once I have dropped this database I will then run the code from section Sample Data to create my sample data to encrypt.

To start the Always Encrypted Wizard I will bring up SSMS on my CLIENT1 machine.   When bringing up SSMS I will connect to SERVER1 where my Demo_Encrypt_Existing database resides.   I then expand this database until I can see my table named MyConfidentialData.  Next I will right click on my table to bring up the following menu:

MyConfidentialData Table Menu
MyConfidentialData Table Menu

On this menu to start the Always Encrypted Wizard I will select the “Encrypted Columns…” item.  Upon doing this the following window is displayed:

Always Encrypted Introduction
Always Encrypted Introduction

On this window I just click on the “Next>” button.  Upon doing that the following Column Selection window is displayed:

Always Encrypted Column Selection
Always Encrypted Column Selection

Here you can see the columns in my table.  I will select the SSN and DriverLicenseNumber columns by clicking on the checkbox.  In addition to checking the box I will also need to select the encryption type.  I will select Deterministic for SSN, and Randomized for the DriverLicenseNumber column.  When I get done selecting columns my window looks like this:

Always Encrypted Column Selection
Always Encrypted Column Selection

If you look at the window above you will see that I’ve got both the SSN and DriverLicenseNumber checked.  Also SSN is using Deterministic encryption type, where the DriversLicenseNumber is using Randomized encryption.   Also the wizard automatically set the name of the Encryption Key to “CEK_Auto1 (New)”.    Now that I’m done selecting columns to encrypt I click on the “Next” button.  When I do that the following Master Key Configuration window is displayed.

Always Encrypted Master Key Configuration
Always Encrypted Master Key Configuration

On this window I can select the key store provider for my encryption key.  I have two choices:  Windows certificate store or Azure Key Vault.  I just take the default, which is Window certificate store.  I also have the option to select the key source, in my case I’m just going to take the default, which is Current User.  When I click on the “Next>” button the following screen is displayed. 

Always Encrypted Validation
Always Encrypted Validation

Here you can see there are two ways to proceed.  I can either generate a PowerShell script, or have the wizard proceed.  Note the warning at the top of this screen.  When encrypting data it is important to make sure no one else is changing or inserting data into the table you are encrypting.   I just use the default value “Proceed to finish now”.  When I click on the “Next>” button the following window is displayed:

Always Encrypted Summary
Always Encrypted Summary

Here I review the summary, and then click on the “Finish” button.   When I do that the following window is displayed:

Always Encrypted Results
Always Encrypted Results

Once I review the output in this window I click on the “Close” button.  

At this point my data has been encrypted.   The  wizard also create the Column Master Key (CMK), which got stored in Certificate store on my CLIENT1 machine, as well as the wizard defined the Column Encryption key  on SERVER1.

Now let me verify my data has been encrypted, and the DBAs can’t see the encrypted data when logged onto SERVER1 using the “Column Encryption Setting=Enabled” connection properties.   First let me verify my data is encrypted by logging on to SERVER1 with no additional connection properties and running the following select statement:

SELECT SSN, DriverLicenseNumber from MyConfidetialData;

When I run this command I get the following output.

SSN                                                                                                                                  
------------------------------------------------------------------------------------------------------------------------------------ 
0x012713226F8DF676B23D3F74535A453EF0F512A862F6D0D76AC804D64FE99E687889E7A45784F00B0D9EDE0367A151E292AE866D65A8473DC0C3F9E551718826AE 
0x0173FFA327C23DBD5C9C05E17C995C53601036A23518FDEA0377CDA4852744E5FD5444D67E1EC73CFB7A4E06C882CC4BCD39DA1CCA2D008E9B99FFC4A970A31947 
0x01CEBD1B420A229EBEC103E1FF6F32118CDCE0EF1F2B6CA30F406EDFAE4BB05DE35921A15FE283F52E8CCB1623B3809283B468750BDDD3D92FCD50D12D217D1625 
0x0178C288245CA5E02E0AC4329EEC95E1E77F472C8EB7E4B00A05C4C3AFFB43B500CC3E8C749C716C91E3AD41E1B16D54555E5383D775B478F3840444DC4DC23098 
0x01036D999EA3D3C1B787746671FEDAD092C7AD89E63F7F36C7F8C8A68CBBE58C9ACFE38C558769013E687DF0F8CD60E8A96D57F151B89521A02B0F11989B23D96D 
DriverLicenseNumber
------------------------------------------------------------------------------------------------------------------------------------
0x011F0728F7CFC5AAE6022239F980BB1358E7B4202149F2ED4B33AFDF46E43204766A2E66391ACBA982420D9E383A5757B2E5F37BE5DAECAEF94D1BF34E0F5E13A6
0x0182CD7DEA29C639F186A0D5B53EC92E7F2D9C7215C078807C718303542FAEAFE2F436FD2A573DF0D3E6697B3A7AA74A285AE38C763109FDB8D14161317AEF4012
0x010CA713707EB2F90042FD4631CC75CD83D6139C5E2BB05CF382E87AB7B9D139D1F695DBC5DF3334E5F4820E08439E9366CBFB3B036FDD905D6907BFDBC4CDD388
0x0126393EFA2431F1D5BD3BD83A98EE377D1D8FB2F1F79B274B70CB2F3550ACF6D43B52238BCB655E646A00DBA3CE024DC8BBF3064D1DA038D3CA19FA1DFE3BCFCF
0x01442316D2480002089FA95AB59AF86BE1E93A85CF911DD5F0C42DB4D275828CB906AC097813B67C82F2FC3D976B422911700B5A3228A73629E8F3188AAEAFD720

Note:  This output has been formatted for readability

As we can see these two columns do contain encrypted data.

Now let me connect with the additional connection property of “Column Encryption Setting=Enabled”.  Once connected with the additional connection property I run the same SELECT statement as above; when I do that I get the following error:

Msg 0, Level 11, State 0, Line 0

Failed to decrypt column 'SSN'.

Msg 0, Level 11, State 0, Line 0

Failed to decrypt a column encryption key using key store provider: 'MSSQL_CERTIFICATE_STORE'. The last 10 bytes of the encrypted column 
encryption key are: 'F5-97-11-AF-D9-13-D0-CD-74-3B'.

Msg 0, Level 11, State 0, Line 0

Certificate with thumbprint 'D96CB4F691559E0B8753AF160F6663922C4ABE6F' not found in certificate store 'My' in certificate location 'CurrentUser'. 
Verify the certificate path in the column master key definition in the database is correct, and the certificate has been imported correctly into the 
certificate location/store.

Parameter name: masterKeyPath

This error indicates that I can’t decrypt the information when I run my SELECT statement on SERVER1.

The Always Encrypted Wizard is a simple way to encrypt your existing data.  With this method you don’t have to worry about creating keys, migrating your data to a temporary table and then renaming it, as you had to do with the other methods above.  With the wizard all these steps are accomplished behind the scenes.  But keep in mind there are some security concerns regarding using wizard to encrypt existing data.  The user that I used to run the Always Encrypted Wizard on CLIENT1 had sysadmin permissions on SERVER1.  I didn’t research if I could run the wizard with less permission than sysadmin.  Therefore keep in mind if you use the Always Encrypted Wizard to encrypt your data, you might need to temporarily provide the user that is encrypting data using the wizard with elevated permissions in order to use the wizard.  This fact alone might make using one of the other method of encrypting existing data more attractive from a security perspective.

For more information on the Always Encrypted Wizard please review information available here: https://msdn.microsoft.com/en-us/library/mt459280.aspx

Summary

Encrypting existing data isn’t that hard.  As you can see there are a number of different ways to encrypt your data, from wizard based to custom C sharp code. When you decide to encrypt existing data using one of these methods you need to make sure your database admins don’t get access to CMK, and/or non-admin users don’t end up with elevated server rights more than they would need to manage the application data.

See all articles by Greg Larsen

Code to Encrypt Data in MyConfidentialdata table

This C Sharp code moves unencrypted data from MyConfidentialData table to MyConfidentialDataTemp table. 

using System.Data;
using System.Data.SqlClient;
using System.Windows.Forms;
 
// Populated Sales.CustomerPII_Randomized table with data
class AlwaysEncryptedInsert
{
    //Read connection
    SqlConnection conn;
    //Insert connnection
    SqlConnection conn2;
    public AlwaysEncryptedInsert()
    {
        // Instantiate the connections
        conn = new SqlConnection(
          "data source=SERVER1;initial catalog=Demo_Encrypt_Existing;integrated security = False; Column Encryption Setting=Enabled; User ID = AppAdmin; Password = AppAdm1n;");
        conn2 = new SqlConnection(
  "data source=SERVER1;initial catalog=Demo_Encrypt_Existing;integrated security = False; Column Encryption Setting=Enabled; User ID = AppAdmin; Password = AppAdm1n;");
    }
 
    static void Main()
    {
        AlwaysEncryptedInsert scd = new AlwaysEncryptedInsert();
 
        scd.ReadInsertdata();
    }
 
    public void ReadInsertdata()
    {
        try
        {
            // open connections
            conn.Open();
            conn2.Open();
            // issue select statement 
            SqlCommand cmd = new SqlCommand("select ConfidentialID, FirstName, LastName, SSN, DriverLicenseNumber from MyConfidentialData", conn);
            SqlDataReader reader = cmd.ExecuteReader();
 
 
              // iterate tbrough read buffer
            while (reader.Read())
            {
 
 
                // Issue insert into new  temporarhy table table  
                SqlCommand com1 = new SqlCommand("insert into MyConfidentialDataTemp values(@ConfidentialID, @FirstName, @LastName, @SSN, @DriverLicenseNumber)", conn2);
                com1.Parameters.AddWithValue("@ConfidentialID", reader["ConfidentialId"]);
                com1.Parameters.AddWithValue("@FirstName", reader["FirstName"]);
                com1.Parameters.AddWithValue("@LastName", reader["LastName"]);
                com1.Parameters.AddWithValue("@SSN", reader["SSN"]);
                com1.Parameters.AddWithValue("@DriverLicenseNumber", reader["DriverLicenseNumber"]);
                com1.ExecuteNonQuery();
            }
        }
        finally
        {
            // Close the connection
            if (conn != null)
            {
                conn.Close();
            }
            if (conn2 != null)
            {
                conn.Close();
            }
        }
 
    }
 
}

See all articles by Greg Larsen

Share:
Home
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved