Generating Typed ResultSets
When the CustomTool property on an XSD schema file is set to MSResultSetGenerator, typed ResultSet datasource objects are generated instead of the usual typed DataSet datasource objects. ResultSets are fast database cursors that support UI data binding, backward and forward scrolling through the data, and the updating of data in the database. As an always-connected model, ResultSets keep a live connection to the database.
Typed ResultSet Features
Generated, typed ResultSet objects provide type-safe access to the database table much like typed DataSets. Thus the generated code ensures that the data that is passed between the application and database correctly matches the database schema at compile time. Typed ResultSet-generated code extends the SQL Server Compact 3.5 ResultSet base class to provide the properties and methods specific to the targeted database table.
The following paragraphs summarize the features of the code that is generated for a typed ResultSet.
Constructors The generated, typed ResultSet contains two constructors. The default constructor is used for both design-time and basic run-time scenarios. The design time of Visual Studio requires the default constructor to connect to the database that is on the local development computer. Thus, the generated code contains a connection string to the local SQL Server Compact 3.5 database file. The default constructor switches for run time to the local SQL Server Compact 3.5 database file from the same directory as the executing application. This is a basic run-time scenario.
Connection strings When the run-time scenario is complex, such as when the SQL Server Compact 3.5 database file is not in the executing directory, or the connection string is varied in another way, such as a password, the overloaded constructor can be used. The overloaded constructor takes two arguments: a custom connection string and a custom ResultSetOptions flag.
Connection property The connection property is the live SqlCeConnection object that is used by the typed ResultSet in order to access the database data. The connection property is public and enables access to manage the state of the connection for the typed ResultSet. For example, the connection may be required to be closed for some transactions.
Typed safe access to table columns The generated code creates a property accessor for each column in the datatable. The property type is determined by mapping the underlying database type to a .NET Framework type. For example, nvarchar is mapped to a .NET Framework string. Because the generated property supports both Get and Set accessors, you can pull and push data by using .NET Framework strings instead of the nvarchar of the underlying database. Each column also has an IsxxxDBNull and SetxxxDBNull method, where xxx is the column name, to make it possible to get DBNull from and set DBNull to the database.
AddxxxRecord method (where xxx is the table name) This method enables new rows to be added to the database table. AddxxxRecord method has one parameter for each column in the data table, except for auto-incremented columns, which have their values assigned by the database engine. Each parameter is again declared as a .NET Framework type, which enables easy use with the application and abstracting out the underlying database type. Update is not required to be called after calling this method. After it is called, the new row is committed to the database.
DeletexxxRecord method (where xxx is the table name) This method deletes the current row from the database. Unlike DataSets, this transition is not cached, and after it is called, the row is deleted from the database. You do not have to call update after calling this method.
Bind method The bind method takes one parameter, a BindingSource, which is data-bound to one or more UI controls on the form. This method then binds the BindingSource to the instance of the typed ResultSet, completing the data-bound chain and enabling the controls to display the data directly in the database.
Note
The design-time scenario requires a hard-coded connection string to the SQL Server Compact 3.5 database. This connection string can get out of date when, for example, a project is shared from one developer to another. As a result, the DataSource window or the Windows Forms Designer or both may not open the project. You can regenerate the typed ResultSet code to correct this situation. In Solution Explorer, right-click the XSD schema file, and then click Run CustomTool.
See Also
Concepts
Resultsets versus Datasets (Devices)