Solution Builder - Channel Insider
Empowering the next generation Channel
 

Bull’s Eye Awards
Nominations Open for Channel Insider 2009 Bull’s Eye Awards
Nominations are now open for the Channel Insider 2009 Bull’s Eye Awards, which recognize excellence in customer service, technology prowess, business acumen, channel leadership, communications and community building, and innovation among vendors, solution providers, distributors and channel services companies.



Sponsored Links
  • Control VM Sprawl, What You Don’t Know Can Hurt You
  • FREE Sophos Encryption Tool: Encrypt, compress and share files easily
  • LSI 6Gb/s Portfolio Expands to Include SATA+SAS HBAs
  • Reduce the cost of managing your mobile workers.
  • Find out 7 Ways to Drive Data Center Efficiency
  • SonicWALL breaks through network and email gridlock
  • Save up to 40% on calling costs with Avaya Aura™



  •  

    Upgrading Typed DataSets in Visual Studio 2005

    in Solution Builder


    Article Rating:starstarstarstarstar / 0
    Article Views: 5871

    Rate This Article:
    Add This Article To:
    Shawn Wildermuth explains how typed datasets change in Visual Studio 2005, and what effect those changes will have on your applications. If anything, he says, Microsoft hasn't changed enough.

    Typed DataSets are a common feature in .NET development projects. With the release this year of Visual Studio 2005 and the .NET Framework 2.0, how will your Typed DataSet projects fare in the upgrade process?

    In this article, I discuss how the 2.0 Typed DataSets differ from the 1.x ones, and how upgrading your projects will affect your use of Typed DataSets.

    While the mechanics of creating Typed DataSets are very much the same as in earlier versions of Visual Studio, the new Typed DataSets try to do much more for you.

    Typed DataSets continue to work in a similar fashion to earlier incarnations, in that the designer is creates an XML Schema Document (XSD) and does code generation based on that xsd. In addition to creating the DataSet, DataTable, and DataRow derived classes, the new Typed DataSet adds a new object that is generated, called a TableAdapter. The TableAdapter's role is to be the data access point for a single table.

    There are several differences between the old version and the new. Among them are:

    • Relationships are automatically gathered from the Server Explorer.
    • A new data access object, called a TableAdapter, is created based on each of the tables.
    • You cannot view the Typed DataSet's XSD unless you open it explicitly in the XSD or XML viewer.

    Before we get too far into theory, let's take a look at the process of adding a Typed DataSet to your application.

    A Walkthrough of 2.0 Typed DataSets

    To add a Typed DataSet to your project, pick "Add New Item" from the menu, as seen in Figure 1:

    Figure 1: Add New Item

    Then, pick "DataSet" from the Add New Dialog, as in Figure 2:

    Resource Library:

    Figure 2: Adding a DataSet

    Adding a new DataSet to your project gives you a new Typed DataSet design surface. To add tables to your project, you select tables, views, or stored procedures from the server explorer (as you see in Figure 3):

    Figure 3: Picking Tables, Views or Stored Procs

    Dragging and dropping the tables onto the design surface yields three tables, with relationships and TableAdapters, as seen in Figure 4:

    Figure 4: New Typed DataSet in the Designer

    Straightforward enough, right? Now let's examine each of those features in more detail.

    TableAdapters

    The purpose of TableAdapters is to simplify development. In .NET Framework 1.1, developers were often confused about how DataAdapters and DataSets worked together. By adding TableAdapters to the generated code of Typed DataSet, Microsoft hopes to end some of this confusion.

    TableAdapters are constructed much like DataAdapters (see Figure 5), but they are type-safe. Interestingly, Microsoft decided that TableAdapters should not derive from DataAdapters by default. They contain a DataAdapter that does most of the work, but the DataAdapter itself is not exposed. When the TableAdapter is created, it (by default) creates GetData, Fill, and Update methods. The GetData method builds a DataTable and returns that DataTable. In contrast, the Fill method fills an existing DataTable (usually contained in a DataSet). The Update method (like DataAdapters) updates a DataRow or entire DataTable.

    Figure 5: TableAdapter Properties

    Within the TableAdapter is a "Query" object that you use to create the GetData and Fill methods. You can change these to specify which (or both) to create and rename the methods, as seen in Figure 6:

    Figure 6: TableAdapter Query Properties

    However, the problem with TableAdapters is the same as with DataAdapters. Updating a complex DataSet remains problematic, because there's no support for smart updating based on relationships. With related data, Inserts and Updates must be performed top-down, while Deletes must be handled bottom up. TableAdapters have no support to do this, so you are left to handle this on your own. (On my own site, I offer an option of how to handle this with DataAdapters.)

    Upgrading Your Typed DataSets

    When you upgrade a Visual Studio .NET 2002/2003 project to Visual Studio 2005, your Typed DataSets will migrate seamlessly, for the most part. You should get the same functionality as you had previously. The nature of 1.x Typed DataSets are completely handled in Visual Studio 2005.

    Upgrading the project may only be part of the change, though. To make your Typed DataSets behave more like 2.0 Typed DataSets takes a little more work.

    TableAdapters

    Currently, there is no way to add TableAdapters for migrated DataTables. If you want the TableAdapter style of data access, you have to re-create your Typed DataSets. That's because, when you drag and drop a table onto the Visual Studio 2005 designer, it stores information about the connection and SQL string used to create the TableAdapter and DataTable. Without redoing the work entirely, there is no way to generate that code.

    Because this information is missing, when you try to add the TableAdapter to the DataTable, the option is unavailable, as seen in Figure 7:

    Figure 7: TableAdapters are not available for Upgraded Typed DataSets

    If you plan to continue to use DataAdapters, this should not be much of a hindrance. TableAdapters are more for clarity and simplification than for new functionality. TableAdapters have nearly the same feature set as DataAdapters (in fact, they are implemented using a DataAdapter), so converting to TableAdapters is definitely not required.

    Customizing DataSets

    Another place where Visual Studio 2005 Typed DataSet varies from Visual Studio .NET 2002/2003 is in how Typed DataSet annotations work. Annotations are used to specify specific naming and behavior changes in Typed DataSets. Using annotations was primary done by hand-editing the .xsd to include the codegen namespace. With this namespace, you could rename the plural and singular form of DataTable properties, change the way data was defaulted, and rename the accessors for getting related DataRows.

    When you upgrade a project to Visual Studio 2005, these older annotations are completely supported, and your .xsd is not changed at all. (Whew.) If you make any changes to the Typed DataSet, the old annotations are replaced with new style annotations.

    Yet, even though the behavior is identical, it is important to understand how these new annotations work. This is because the designer still does not support changing these code generation options directly. To get at the annotations, you need to view the Typed DataSet in an XML view. Unfortunately, they have removed the convenient XML tab from the Typed DataSet designer. You can still view it as XML, by right clicking the Typed DataSet and picking "Open With," as seen in Figure 8:

    Figure 8: Open With...

    Once you select to "Open With" the Typed DataSet, you get a dialog box in which you can specify which editor to use. Choose the XML Editor, not the XSD editor, as seen in Figure 9:

    Figure 9: Open With Dialog

    Once you have the .xsd open in the XML editor, you will notice the new style of annotations: they all start with msprop:Generator_. There are two ways to think about the new annotations: "It is good that they include all the annotations, so I can change them without too much trouble," or, "If I don't use the annotations, they just muddy up my schema document."

    Upgrading your Typed DataSets does not have to be a harrowing experience. Luckily, Microsoft has taken the tack that it should be as compatible as possible. But they have not gone quite far enough, in my opinion. Hopefully, this article will help to streamline your move from Visual Studio .NET to Visual Studio 2005.

    Here is a list of the annotations and what they are for. They don't seem to be documented, so be wary of the possibility of changes in the future. In upgraded Typed DataSets, these should be used instead of the older style annotations.

    Annotation (all start with 'msprop:') Valid On Description
    Generator_UserDSName DataSet Unknown (no effect detected)
    Generator_DataSetName DataSet Name of the DataSet class.
    Generator_UserTableName DataTable Name of the Table accessor on DataSet
    typedName DataTable Name of accessors that take the singular form. (Older form, use Generator_TableClassName instead.)
    Generator_RowClassName DataTable Name of the DataRow class for that table
    typedPlural DataTable Name of accessors that use the plural form
    Generator_TableClassName DataTable Name of accessors that take the singular form
    Generator_TableVarName DataTable Name of the variable for a table in the DataSet class
    Generator_TablePropName DataTable Name of the DataSet property for that table (overrides Plural form)
    Generator_RowEvArgName DataTable Name of the RowChanged Event Argument Class
    Generator_RowEvHandlerName DataTable Name of the RowChanged Event Handler class
    Generator_UserColumnName DataColumn Unknown (no effect detected)
    Generator_ColumnVarNameInTable DataColumn Name of the local variable in the Table
    Generator_ColumnPropNameInRow DataColumn Name of the property on the Row
    Generator_ColumnPropNameInTable DataColumn Name of the Column property on the Table
    nullValue DataColumn Specifies what is returned if the column is null. Literal value or _null or _empty are valid.
    rel_typedChildren DataRelation The name of the Method to get children of a Row. (Older form, use rel_Generator_ChildPropName instead.)
    rel_typedParent DataRelation The name of the property to get the parent of the Row. (Older form, use rel_Generator_ParentPropName instead.)
    rel_Generator_ChildPropName DataRelation The name of the Method to get children of a Row
    rel_Generator_ParentPropName DataRelation The name of the property to get the parent of the Row.





    Discuss Upgrading Typed DataSets in Visual Studio 2005
     
    >>> Be the FIRST to comment on this article!
     

     
     
    >>> More Solution Builder Articles          >>> More By Shawn Wildermuth
     


     


    [ci] feeds
    XML
    Add Channel News, Product Reviews, Trends and Analysis to your RSS newsreader or My Yahoo!


    HTML PLAIN TEXT

    Keep on top of news for VARs and Resellers with CI's Weekly Newsletter and Alerts.

     


    CHANNEL RESOURCE CENTER
     
     
    Enterprise Mobility Zone
    The Enterprise Mobility Zone (EMZ) blog is a tool designed to help senior IT executives discuss, create and deploy next-generation mobile strategies in their organizations.
    Go beyond yesterday's tactical approach to mobility!
     
    Build A More Efficient Data Center
    Demands are growing but budgets are not. Solve your pressing IT issues using the resources you already have. Determine which technologies can help you drive efficiencies and how they are applied. Gain a quick ROI on new initiatives
    Find out how
    Let Enterprise TechBrief do the work for you. Aggregated content, tech news, product reviews, vendor updates, how-to’s—all you need to boost your efficiencies and cut costs, all from one place.
    enterprisetechbrief.com