Microsoft has released a number of exciting new tools and technologies that certainly bear some watching! These are preview releases so the usual caveats apply about installing these on a production system.

The "home" page for Microsoft's Data Platform is here and it contains the most up to date information about the various shiny new pieces.

The main bits are ADO.NET Entity Framework Beta 3, ADO.NET Data Services CTP1, and ADO.NET Entity Framework Tools CTP2.

So what exactly is the Entity Framework? It's a toolset and framework that enables a developer to visually design and model data driven applications, both forms based and web based.

Collectively these technologies are part of the ASP.NET 3.5 Extensions which are in preview mode at the moment. Combined these technologies allow a developer to expose data from their applications in well known formats, some of which are not Microsoft specific such as JSON and REST and also in standards based formats such as XML.

There are a number of QuickStarts that the ASP.NET team has made available. Also as part of this release the ASP.NET MVC framework is available.

Go check it out!

 


 
Categories: .NET | ADO.NET | Ajax | ASP.NET | Programming | SQL | Visual Studio


In the last (and first) post of this series we discussed how to create a typed dataset. Now that we have our dataset we need to see how to use it.

But before we go into the details, I want to explain something that I stumbled upon in my research. There is a serious bug in the implementation of the dataset generator. It effects retrieving and manipulating childrows when you are dealing with related tables.

After a great deal of hair pulling, self doubt, and serious coffee consumption, I finally found a series of blog posts that ended up leading me here. The bug has been confirmed and will be released: “thanks again for reporting this. We fixed this problem and the fix will be available in the next Visual Studio release.”

Description
When you create a typed DataSet using the class-designer of VS.NET with a parent- and a child-table, a method is generated on the parentrow-class which should return the childrows. This method uses DataRow.GetChilds with the name of the relationship. This method returns a parentrow-array instead of a childrow-array. The generated method casts it to a childrow-array and thus causes a InvalidCastException.
This bug reduces some of the functionality of the typed dataset in production applications. There is a workaround, but it is a simple kludge, and the end result is that you cannot easily work with related data.
 
Ok, with that said, lets continue on with the series. Next post in this series will take us back into the thick of it. There is still a huge benefit to using typed datasets, just sad that this bug caused such an unfortunate loss of some of that functionality.
 
Cheers,
 
Robert Porter

 
Categories: .NET | ADO.NET | Programming | SQL | VB.NET | Visual Studio | XML


The first thing we need to do is to create the actual dataset. There are a number of ways to accomplish this, however I have found that the most straightforward way is to right click your solution, select Add… then select Dataset from the list.

Datasets can contain many tables or queries or both, I tend to create a dataset per table unless I need to work with joins or multiple tables at once.

There are also a number of options involved in creating a dataset, we are going to explore several of them in this series. The most significant decision you will need to make is whether or not to base your dataset on Stored Procedures or Queries.

In this first example we will be using Queries. But first we need to create the dataset. Once you have selected Dataset you should give it a name, I typically use the table name it is going to be based on, in this example, Employees.xsd

The Dataset Designer will appear, a mostly blank screen that we will drag objects from Server Explorer onto. Go to the Server Explorer window, if it is not visible you can pull down the View menu and select Server Explorer. You should see something like Figure 1: Figure 1.

The Data Connections node is what we are going to work with, right-click it and select the Add Connection… option. Fill in the resulting dialog to connect to your instance of SQL Server and make sure the database selected is “pubs”.

Expand your connection and you will see a listing like Figure 2: ServerExplorer2

As you can see we now have access to a number of items within the database itself, most importantly for this example, the Tables node.

Expand the Tables node and drag the ‘employee’ table onto the dataset designer surface. By default you will get an ‘employee’ dataset and an ‘employeeTableAdapter’ with two methods, Fill and GetData().

Behind the scenes a great deal of code has been generated for you, or will be once you press Save. But we don’t want to accept the defaults, so we are going to make some adjustments.

The first thing you should know is that the process of dropping the table onto the designer surface persisted the connection you created in you applications app.config file. It will have created the app.config file if one did not already exist.

In a production application you would want to alter this connection string to match the production servers connection parameters as well as probably encrypt it. For this example I would suggest that you open your app.config file and rename the connection to “pubs”. My ConnectionStrings section contains the following:

    <connectionStrings>
        <add name="pubs" connectionString="Data Source=DELLXPS;Initial Catalog=pubs;Integrated Security=True"
            providerName="System.Data.SqlClient" />
    </connectionStrings>

I will show you later how to use this renamed connection string as opposed to the one the dataset will be expecting, and explain why I do that.

Next, we need to tweak some of the defaults created for us by the designer. Right-click the employee Dataset and select Configure from the context menu.

You will see a TableAdapter Configuration Wizard pop up. It will show you the query it is using to build and populate the dataset. Click the “Advanced Options…” button and make sure all 3 checkboxes are checked. They usually are by default. The first option tells the designer to create Insert, Update and Delete statements that match the Select statement used.

The second option tells the designer to Use optimistic concurrency which adds intelligence to the Update and Delete statements to allow them to detect if the record(s) they are about to Update or Delete have been modified since they were populated.

The final option, “Refresh the data table” fires a Select after every Insert and Update statement in order to retrieve calculated fields, default values and identity values that are generated by the database.

Once you have done that, return to the Wizard and select Next, you will get the Choose Methods to Generate screen. You will see 3 options, the first two are what we are concerned with for now.

All 3 should again be checked, modify the names of the methods to better reflect what they are doing, in this case returning all employees. See Figure 3 below for an example:

MethodsGen1

Press next once more and you will get Wizard Results screen that shows that the designer has generated all the code, queries and methods we asked it to.

Review the results, then press Finish to return to the designer. Your dataset should now look something like this in the designer:

ModifiedDatasetNotice the highlighted section, this shows that the method names have changed like we wanted.

Thats it! You have now created your first strongly typed dataset.

Next up, we will discuss what exactly this does for you, and how you would use it in code and what advantages you gain from using this construct.

Stay tuned!

Bob Porter

 


 
Categories: .NET | ADO.NET | Programming | VB.NET | Visual Studio | XML


November 28, 2006
@ 11:11 PM

This post is my first attempt to share some of my own experience. Specifically with ADO.NET and Typed Datasets. Scott Guthrie published an excellent series of tutorials on creating a DAL using Typed Datasets.

This is not an attempt to duplicate that series, but it is inspired by it. And I also wanted to do this from a Winforms perspective rather than an ASP.NET view, since I still work in both worlds.

For my first effort, I created a fairly simple application that allows the user to perform simple, Select, Update, Delete and Insert operations against the SQL Server sample pubs database employee table.

SQL Server 2005 does not ship with the pubs or Northwind databases any longer. If you want the scripts to create them you can download them here. These scripts while designed for SQL Server 2000 worked just fine in SQL Server 2005 and created the databases and populated them with data. (They also include pre built databases in the form of MDF and LDF files that you can attach but I prefer to build them from the scripts.)

If you want to download the sample application that goes along with this series of tutorial posts you can do so here. File Attachment: MasterDetail001.zip (71 KB)

I am going to begin this series in earnest tomorrow with the first of the “meat” posts. And let me clearly state, the code in the sample app is very basic, little or no error handling, and not necessarily even the correct way of doing things. I am looking for constructive feedback myself. This application, as it grows, and the tutorials that accompany it are as much a learning exercise for me as anything else.

Cheers,

Bob Porter


 
Categories: .NET | ADO.NET | Programming | SQL | VB.NET | Visual Studio | XML


January 2, 2005
@ 12:41 AM

Hmmm