Gravitybox Software

Data binding is the process of binding a schedule directly to a dataset. VS.NET defines an object named Dataset. This object can effectively hold multiple database tables. This discussion assumes that you have used datasets before.

Since every application has its own structure and data, you may think that it would be impossible to bind a schedule to an unknown database. The schedule is quite flexible in that it can bind to a dataset with minimal data. In addition a dataset can be expanded to encompass many optional fields. There are also some other constraints on the dataset structure to make it compatible with the schedule. However none of these are overbearing and you can create a compatible dataset from your database quite easily.

A dataset can be defined visually using the Visual Studio environment. In this fashion you can create a strongly typed dataset with appropriate columns and constraints. You can view the dataset on screen and modify it. A strongly typed dataset is derived from the “System.Data.Dataset” object. Alternatively you can create a dataset in code. This second method is described in the example below.

When creating the dataset there are a few constraints on its structure. First, there must be a table defined in the dataset named “Appointment”. This table must contain the columns appointment_guid, start_date, start_time, and length with the data types string, date, date, and integer respectively. All of these columns must be marked to disallow DbNull and the appointment_guid column must be marked as unique. This is the minimal set of requirements. If any of these requirements are not met, the schedule will throw an error when the dataset is bound.

The following code snippet defines a minimal dataset in code.

'Create a dataset with an "Appointment" table Dim ds As New System.Data.DataSet Dim dt As System.Data.DataTable = ds.Tables.Add("appointment") 'Create the necessary columns dt.Columns.Add("appointment_guid", GetType(String)) dt.Columns.Add("start_date", GetType(Date)) dt.Columns.Add("start_time", GetType(Date)) dt.Columns.Add("length", GetType(Integer)) 'Mark to disallow DBNull dt.Columns("appointment_guid").AllowDBNull = False dt.Columns("start_date").AllowDBNull = False dt.Columns("start_time").AllowDBNull = False dt.Columns("length").AllowDBNull = False 'Mark the 'appointment_guid' column as a unique key dt.Columns("appointment_guid").Unique = True

This empty dataset can be bound to the schedule as follows, where the name of the schedule is Schedule1.

'Bind the dataset to the schedule Schedule1.DataSource = ds

When the schedule is bound, all appointments on the schedule are cleared, so be sure there are no appointments that you need. After the AppointmentCollection is cleared the newly bound dataset is used to populate the schedule. In the example above, the dataset is empty so no new appointments are created. The dataset always reflects the state of the schedule. This means that as the user operates on an appointment by add remove, move, etc, the dataset is updated. The opposite is also true. If the dataset is modified outside of the schedule while it is bound, the changes will be reflected on the schedule as well. This means that you can commit the dataset back to your database at any time and the changes will be current.

This also creates an interesting corollary. If a dataset is bound to two or more schedules simultaneously, all schedules will be synchronized at all times. This occurs because if one schedule is changed it updates the bound dataset. However since the dataset is bound to another schedule, the second schedule is notified that the dataset was updated and the second schedule is updated as a result. This functionality allows you to synchronize multiple schedules simply by binding each to the same dataset.

Although appointments are the most important table, you may also bind to other dataset tables as well. If your dataset has a properly formatted Room or Provider table the schedule will load its respective collection from these tables. The Room table must have a room_guid and name both of type string set to not accept null values. It may also have an optional notes field of type string. The Provider table has the same format and rules of the Room table with the additional, non-nullable, required integer field of Color with the exception that the key is named provider_guid.