The most common case is a bound table (DataMode = Bound) where a table has non-empty Connection and DbTableName properties. In this case, a table is based on a database table, so all database access operations can be performed by DataObjects for .NET automatically. There is no need to write custom code fetching and updating the table data (although it is possible to customize the default behavior in code).

In more complicated cases, there may be a need for more flexibility. For example, you may need to use a complex, non-standard SQL statement to fetch table data, or to use a stored procedure. Normally, for a bound table, the SQL statements fetching and updating data are generated by DataObjects for .NET. If that is not adequate, you can use a SQL-based table (DataMode = SqlBased). A SQL-based table has non-empty Connection property and empty DbTableName property. Instead of DbTableName it uses the SelectCommandText property where you can specify a SQL statement or a stored procedure depending on the SelectCommandType property setting.

To define a SQL-based table, set the DataMode property to SqlBased, set the Connection property, leave the DbTableName property empty, and specify the SelectCommandType and SelectCommandText properties.

Using a SQL-based table can be almost as easy as using a bound table, if you create a DataAdapter component for it. A DataAdapter component can be created in a C1TableLogic component associated with the table by selecting Create DataAdapter from its context menu. The DataAdapter component will then perform both fetch and update without custom code (but you can customize the default fetch and update behavior in event code if needed).

Although SQL-based tables are almost as easy to use as bound tables, bound tables are always preferable when you have a choice. Bound tables are more intimately related to database tables, so DataObjects for .NET can support features that are impossible for SQL-based tables; for example:

• Only bound tables can be combined to form a composite table. SQL-based tables cannot be used in a composite table.
• Only bound tables can be used in virtual mode (with large data sets), SQL-based tables cannot.
• FilterCondition in Fill does not work with SQL-based tables without additional coding, because DataObjects for .NET does not generate SQL statements in this case, so it cannot automatically modify the SQL statement by adding the condition to its WHERE clause. You need to do it in code, in the AfterGenerateSql event.

If you want even more control over fetch and update process, you can use a SQL-based table without DataAdapter component and even without setting the SelectCommandText property. In this case you perform fetch and update by generating SQL statement(s) in code:

• To fetch data for an SQL-based table, write code in the BeforeGenerateSql event setting the Sql event argument to the SQL statement fetching data and set the Status argument of the event to Skip. Note that since it resides in a C1DataSetLogic component, this code is attached to table views based on this table, rather than to the table itself. This is in keeping with the general rule that data is fetched by table views, not by tables; for more information, see How the Data is Fetched.
• If the table is updatable, write code in the C1TableLogic BeforeUpdateRow event. In that code, you can specify update, insert and delete commands, or perform the update in any desirable custom fashion.

You can also combine these options, using these custom SQL statements created in code with a SQL-based table with DataAdapter, or, for that matter, event with a bound table. For example, you can fetch data without custom code, using DbTableName or SelectCommandText properties, and update with custom code.

If you need even more flexibility than provided by SQL-based tables, for example, when working against a non-SQL data source, you can use an unbound table. An unbound table is a table with both DbTableName and Connection properties empty (set the DataMode property to Unbound). Fetching and updating data for an unbound table is done in code, for example:

• To fetch data for an unbound table, write code in the BeforeFetch event. In that code, create a reader object implementing the System.Data.IDataReader interface (either use a standard .NET Framework implementation such as OleDbReader or SqlDataReader, or, for custom data, create an UnboundDataReader object), fill the reader with data, assign it to the Reader event argument and set the Status argument of the event to Skip. Note that, as in SQL-based tables, this code is attached to table views based on this table, rather than to the table itself, according to the general rule that data is fetched by table views, not by tables. For more information, see How the Data is Fetched.
• If the table is updatable, write code in the C1TableLogic BeforeUpdateRow event. In that code, perform the necessary update programmatically and set the Status event argument to SkipCurrentRow, indicating that the update has been done.