SQL Server 2005 Compact Edition

Tutorial:

CRUD - (Create, Read, Update, and Delete)

By: Chris Conley

cconley@c-solutions-inc.com

C Solutions, Inc

www.c-solutions-inc.com

O) (918) 307-0991

Copyright 2007

For single tier applications, I love SQL Server Compact Edition 2005. It gives you the

database accessibility of SQL, all while not needing access to a server install of SQL

Server. Over the years Microsoft has offered a number of other ways to work with data

in single tier applications, but none have been nearly as comparable, nor effective for me,

and SQL Server compact edition. To name just a few of these previous data access

modes that were available by Microsoft, XML files, and access databases. Both of these

had their own limitations and frustrations. For XML files, querying them was a pain, not

to mention speed, or lack of security. While Microsoft Access forced you load on the

client computer the Microsoft Jet database. This database system, left a bit to be desired

in the security category as well.

SQL Server Compact Edition 2005 is a great leap forward in single tier applications. In

case you didnt know, single tier applications are ones where the application interface and

data are on the same computer.

Some of the great leap forwards that SQL Server Compact Edition are:

The database files can be encrypted with RSA 128 bit file encryption

Supports databases files up to 4GB

Data can be accessed with a subset of T-SQL

Support for transactions

Can be run in a Windows, or in a Windows mobile application

Supports data synchronization

Database engine uses about 5 MB of memory and about 2 MB of disk space

One of the best things about it all is, it's free.

In order to run the examples shown below, you must first install SQL Server 2005

Compact Edition, as well as Microsoft SQL Server 2005 Compact Edition Tools for

Visual Studio 2005 Service Pack 1. Both of which can be found in a search from the

Internet.

Now to go over how you can actually use this in a Windows application.

First, to add a new SQL Server 2005 Compact Edition database, we select from the

Data Sources tab, Add New Data Source.

Click this, then it will bring you to the Data Source

Configuration Wizard dialog box. On this, hit the

Database option.

This will take you to the next

screen, which allows you to

choose your data connection.

Click the button that says New

Connection.

This will take you to the next screen, entitled

Add Connection. Change the data source

from the default of SQL Server to SQL

Server Compact Edition. To do so, hit the

Change button to bring up this screen,

Change Data Source. After you hit the OK

button, it will bring up the following screen,

also called Add Connection.

Add Connection Screen

On this screen, the first thing you need to do is add the location of your database. To do

so, hit the Create button. This will take you to

the next screen, where you can create a new SQL

Server 2005 Compact Edition Database file. As

you can see below, I've called mine

SSCE_CRUD. FYI. All SQL Server 2005

Compact Edition Database files are given in an

extension of .sdf. As you can see, you have the

chance to do a couple other things on this dialog

box as well: encrypt the database by selecting the

similarly named checkbox, and setting a

password by simply entering in the new

password and then filling in the confirmation

textbox below. Remember, encrypting the

database and setting a password are optional. Of

course depending upon your applications needs,

you may or may not want to do this. Also,

Microsoft warns the encryption level they use on

this file is not set for the highest level of security, so, they do say it is very safe compared

to non-encrypted, but far from being unbreakable security for the file.

For the purposes of simplicity for this tutorial, I gave a password of password. As you

can see from the screen below, the system really does not like this password and requests

one of a much higher level. It does give you the option of allowing you to use whatever

password you want, though, even if it does not meet its recommended minimum

complexity

requirement it

gives you.

So, I selected yes to continue with this password.

Our Add Connection screen

now looks like this:

If you want to be paranoid, you

can hit the Test Connection

button which should show you

that the test connection

succeeded. Now simply hit the

OK button.

Now you can see our new

database file in the

updated Data Source

Configuration Wizard

dialog box:

Now it's wanting to

know if you would like

the application to keep

sensitive connection

string information, or

exclude it. I always select

no, exclude sensitive data

from the connection

string. I prefer setting this

in application code. After

you've selected yes or no,

from the radio button list,

hit the next button on the bottom of the dialog box to continue. After having done this, I

was greeted with the dialogue seen below:

I tell its yes with the yes button.

Then it gives me the next dialog box:

I tell it no I want to use the existing file, by hitting the No button.

Then the next screen by the fall has the Yes checkbox selected. I preferred to uncheck it

so it looks like the screenshot below. This is because I do not want to say the connection

string in the application's configuration file. If you like, you can leave the yes checked.

Then hit the Next button.

This takes you to the screen below, which, I simply hit Finish because I do not want to

add any database objects at this time.

Now that we've got our database created we can get down to doing some work on our

Windows form. I have changed our default forms text property to Days Of The Week. I

have added a label, whose text

property is set to Weekday.

And I have added a button,

whose text property is set to

Insert, and name set to

btnInsert. I like to add on all

of the components I use it,

which I'm going to do any kind

of programming against, the

first two or three letters, or

more sometimes, of the name

property I give to it to be

descriptive of what the

component is. So I can look at

it in code, say, in a printout,

then I can intuitively know

what the component type is without having to look at the Design view screen. I have

also added a text box to the screen, whose name property is txtWeekday. The txt in

the name property is for the same reasons as outlined in the sentences above.

Also, if you look in the Solution Explorer

under references, you will find a reference is

already setup for you for SQL Server

Compact Edition 2005.

The application, however, does not know where you will be using SQL Server Compact

Edition (SSCE), so you must give it a reference to it wherever you may use it in code so

the compiler will know what you're talking about. For simplicity sake, we will do all of

our coding in the code behind of Form1. To access this, I simply double-click in design

view of form1 to access the code behind for Form1. Here you can see I've added a

reference, as shown in the using statement, to SQL Server Compact Edition. Also you

can see I've added a private to the form variable of type SqlCeConnection called

cnSQL_CE. And I've also added a method call CreateConnection, which, go figure,

creates the connection to SQL Server Compact Edition. Since we're doing this with a

variable that is global to the form, this variable will be available to other items in the

forms code as a local variable. Also, to clean up after ourselves, and keep the system

happy, I have added to the form close event a call for the SQL Server connection variable

to run its close method, to close its connection to the database.

Now that we've created a connection, in code it least, to the database, it would help if

we actually created a table for the

database. So let's do that now. Go to

the Server Explorer, then select your

new database as I have done, then

right-click on it, and then click and

choose 'Create Table. This takes you

to the next screen, as seen below.

Here you have the opportunity to add in your database fields. I have added an identity

column named ID, as well as another column named WeekDayName for our

weekday. When you are done, simply hit the OK button.

Now youve got a database table for SSCE. Let's put it to use. Now add code to add a

record to the database. First, we need an event for the record to be added, so let's go to

the click event for btnInsert by double-clicking on the button marked Insert on our

form to access its click event. After doing this works most of the code view for the click

event. Here we will add the code as seen below.

So, now all we need to do is run our program, type in a weekday into the textbox, and

then hit the insert button. This will then add a new record to the table. I put in the textbox

the value of Monday.

After you've done this, you can go to Server Explorer and see the new data. But, to do

so, you need to create another connection to the database. This time, it needs to point to

the applications bin directory, as that is where I have coded for the database operations

to be performed. The original connection we made to our SSCE data is to a copy which

resides in the same directory as our source code. When we created the database, the

system automatically made a copy of the database in the source code directory and place

it, the copy, into the bin directory.

After thats done, we can see our data in

the database table like this:

So, now, it maybe nice to be able to see what data is in the table without having to go to

this length of trouble. This is the R in our CRUD Read. So let's now add code and

functionality for a Select button. Add a button, whose text property is Select, and I'm

going to give mine the name of btnSelect. Next, let's add code for our button to create a

DataTable from the data in our table. Then, set the textboxes text property equal that

which it finds in the first row of the DataTables WeekDayName field. Here's the code

for that below:

So, when your application gets to the code for the Select button, it will query the

database, and get all the data in our new table and put that into a DataTable. It gets the

data from our created SqlCeCommand object which uses are global variable connection

of cnSQL_CE. Then we use the SQLCeDataAdapter variable we created to fill the

DataTable with our data. Then our code puts into a string variable what it finds in the first

row of the table from the WeekDayName field. Of course, there's a lot of problems with

the way this is written, from a technique point of view. We have no try catch handling for

the database access, nor do we have any accommodation if there is not a record in the

database table. This would cause their message to come up if there was no data in the

table. But, as this is an article on SSCE CRUD, I am not worrying about, nor addressing,

those issues in detail. The payoff to all this is you should see when you rerun your

program, then hit the Select button, your form look like this:

Now is the time for our U part of CRUD Update.

First, lets add another button to our form, whose text property is Update and name is

btnUpdate. Next, double-click on the newly created update button and add the code you

see below.

As before, I have to add a few caveats to this code. As you could probably see, it is

hardcoded only to update the record, whose ID is equal to 1. Of course, if you did not

have an ID, which met this parameter, the update will fail. A much better way of doing

this would be to programmatically set the ID of the record you would like to update, but

as said before, this is an article on CRUD, and I am not worrying, nor covering such

specifics. You can see in the code, as we head used in the Insert method, we are using the

SqlCeCommand object variable to carry out the update, and also using our global SSCE

database connection, cnSQL_CE.

Last on our list, we have D, the Delete in CRUD

As before, at a new button to your form, said its text property to the value Delete, and

its name property to btnDelete. Next, add the following code you see below. You will

notice the reappearance of our friend the SqlCeCommand object, which will be used to

carry out our delete SQL statement in the same manner as we just carried out our update.

Now a few caveats, as before. In this example as well, we'll hardcoded the ID of the

record we are deleting. In a real world application, of course, this would not be

acceptable, but for the use of this article it shows how the delete operation can be

performed.

Well, you've made it. You've seen how to create a SQL Server Compact Edition 2005

database from scratch, set it to use 128 bit encryption, assign a password to the database,

add a new table to the database, and how to build a Windows form application that allows

you to add records, select and show records, update records, and delete records. That's a

lot.

There are some limitations with SSCE, though. One of them is it cannot be used in web

applications. Microsoft has IIS, or SSCE, configured, where they will not allow a SSCE

database to operate in a web application. Microsoft strongly recommends, instead, a full

instance of SQL Server to be used, of any version from say, Express on up. So, don't get

excited and think you will be able to do web applications with SSCE, because it will only

meet and failure. SSCE is made for strictly Windows applications only.

Also, SSCE does not support stored procedures.

But, clearly, there are a great number of things you can do in Windows applications

with SSCE. It is a giant leap forward from what we have available previously. I would

very strongly recommend the full version of SQL Server or any applications which are

two tier, or more, but for single tier applications I think SSCE is great.

Deployment

As far as deployment is concerned, Microsoft has a msi install file available to load

on the client for use of SQL Server and Compact Edition. But, being a control freak that I

am, I like to add the necessary files to the applications runtime directory. Here's a list of

the files needed for successful deployment of a SSCE application.

System.Data.SqlServerCe.dll

sqlceca30.dll

sqlcecompact30.dll

sqlceer30en.dll

sqlceme30.dll

sqlceoledb30.dll

sqlceqp30.dll

sqlcese30.dll

FYI. On my computer, the only one that was natively in my applications directory was

System.Data.SqlServerCe.dll. The rest were in a directory below my VisualStudio

installation called \Common7\IDE.