Managing DataTable Classes in the Data Source Designer


When a Data Source .XSD file is exposed in the Data Source designer, each TableAdapter in the Data Source is displayed on a GUI surface. If the DSCW discovers that the TableAdapter DataTables have primary keys that match other tables, it generates appropriate Relationship instances in code and, when the XSD is displayed, the Data Source designer draws relationship lines between the DataTables, as shown in Figure 6.42.

Figure 6.42. A populated Data Source showing intertable Relationships.


IMHO

You can arrange the individual DataTable graphics anywhere on the designersorta like a mini-database diagram, but without many of the features.


The relationship lines indicate that the TACW has generated DataRelation instances for each of these relationships. This is a new feature of Visual Studio 2005 that was missed by those working with hierarchical relationships in earlier versionsthey had to be hand-coded before. The question is, how does drag-and-drop deal with intertable relationships? The answer: It doesn't.

Setting DataTable Properties

This interface can also be used to set a few properties on the DataTable. Only a couple of these are interestingand one does not seem to work at all. If you right-click on a DataTable and choose "Properties", the Visual Studio property page focuses on the DataTable properties:

  • CaseSensitive: This property determines if the string comparisons on this DataTable's text columns use case-sensitive or non-case-sensitive comparisons. For example, if you wanted to set a WHERE clause parameter to "MAC" to find all authors whose name was "MACintosh" but exclude those spelled "Macintosh", you could set the CaseSensitive property to True. This (and the Locale properties) might have been more useful if they applied to a specific column instead of the entire DataTable.

  • DisplayExpression: There is very little known about this property. It seems to require a simple expression to set the value of a specific column. For example, I might have been able to set the Age column to "Age=2005-Year_Born". However, once I set this value, there was no sign that this did anything to the contents of the bound controls.

  • Locale: As with the CaseSensitive property, Locale determines the locale to use when comparing strings in the DataTable.

  • Name: This simply renames the DataTable in the TableAdapter.

The Generated Form Code

Most of the code generated by the drag-and-drop operation is created behind the scenes. However, this process also adds (at least two) routines to the Public Class code that you'll have an opportunity to modify or screw up. These code segments are shown in Figure 6.43.

Figure 6.43. Code generated by drag-and-drop in the Public Form class.


The first routine (fired when the user clicks the "Save" icon in the BindingNavigator) ensures that any pending changes made to any bound controls are committed to the underlying DataTable (EndEdit) and subsequently call the Update method on the TableAdapter. This, in turn, calls the DML action commands defined in the TableAdapter. I showed you the generated code for the UpdateCommand in Figure 6.30.

The second routine captures the parameters from the Fill ToolStrip control and passes them to the TableAdapter Fill method. This method opens the Connection, executes the query, and populates the DataTable Rows collection with the rowset returned from the query.

Note that the exception handler generated is kinda sparse. I expect you'll want to flesh this out a bit for a production application.




Hitchhiker's Guide to Visual Studio and SQL Server(c) Best Practice Architectures and Examples
Hitchhikers Guide to Visual Studio and SQL Server: Best Practice Architectures and Examples, 7th Edition (Microsoft Windows Server System Series)
ISBN: 0321243625
EAN: 2147483647
Year: 2006
Pages: 227

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net