Visual Basic has been a popular development environment for years now, and it is used for everything from quick-and-dirty single-user applications to sophisticated commercial software products. Because it's a general-purpose tool, it appeals to a wide ra nge of developers. That same breadth of appeal also means that in the database area, Visual Basic lacks some of the specialized features of products such as PowerBuilder and SQLWindows.
This is where Data Director 2.0 from CenterView comes in. Formerly known as Choreo, Data Director is a tightly integrated development extension for Visual Basic 4.0 that adds both design-time and runtime functionality. At design time, Data Director seaml essly extends the Visual Basic development environment, providing additional functionality through menus, dialogs, controls, and palettes. At runtime, it manages all SQL commands, data synchronization, and display, through what CenterView calls a model-d riven data access engine.
Does every developer building a database application with Visual Basic 4.0 need Data Director? The answer is no: Not all developers will choose to work in a model-driven environment, and not all applications can be built with non-procedural tools. Howeve r, many applications are candidates for Data Director, such as those in which the developer would rather not write SQL code to access the database and would rather have multi-user concurrency issues handled automatically. This situation implies a well-de signed database with all necessary primary and foreign keys defined in the schema and no show-stopping performance issues that require hand-tuned SQL to achieve adequate response time.
Three terms must be defined in order to understand how Data Director works: Models, DataGroups, and DataLinks. By way of analogy, a Model is similar to a database schema, a DataGroup is similar to a view, and a DataLink is similar to a column in the sele ct list of a query.
To create a Model of a database, Data Director imports schema information from a wide variety of SQL DBMSs. The Model stores information about the database characteristics such as table names and column data types, which columns are primary keys and whic h are foreign keys, and how the tables in the database are related to one another. Models are stored in both text (.MLT) and binary (.MLX) file formats, and Data Director uses the text Model file at design time and the binary Model file at runtime. This structure means that any applications built with a given Model must be distributed with the appropriate binary Model file. When the structure of a database that has been imported into a Model changes, it is necessary to synchronize the information in the database and the Model. Data Director has the ability to refresh a Model with any changes that have occurred in the underlying database.
The Data Director user interface for working with Models is called the Model Viewer. Figure 1 is an example of the Model Viewer showing the tables in a Model, the relationships for a selected table, and the properties for a selecte d column in the table.
Each DataGroup contains a subset of the tables in a Model, and the Model determines which database to access. The same Model may be used for more than one DataGroup, and an application may access multiple Models. Generally, a DataGroup is based on one bu siness process. The number of processes an application performs usually determines the number of DataGroups in that application. For example, an order entry DataGroup might include tables named customers, orders, and order_lines.
A wide variety of properties can be defined to control the behavior of a DataGroup: General, Query, Error Handling, Database, Connection, Concurrency, BLOB Support, and Joins. Figure 2 shows the options for the Concurrency properti es of a DataGroup.
When you create a DataLink between a text box named Employee Name and a database column that stores employee names, the text box displays employee names in a running application.
Because a DataGroup references a Model, Data Director automatically knows about the relationships in the Model. For example, a one-to-many relationship in a Model tells Data Director to query the detail information for the master records if DataLinks to the detail records exist.
The Data Director user interface for working with DataLinks is called the DataLink Manager. Figure 3 shows DataLinks on the right-hand side of the DataLink Manager window, with mapping between controls on a Visual Basic form and co lumns from three tables in a DataGroup named CustomerService.
