Common use of Overview of the Database Desktop Clause in Contracts

Overview of the Database Desktop. The Database Desktop (DBD) is a database maintenance and data definition tool. It enables programmers to query, create, restructure, index, modify, and copy database tables, including Paradox and dBASE files, and SQL tables. You do not have to own Paradox or dBASE to use the DBD with desktop files in these formats. The DBD can copy data and data dictionary information from one format to another. For example, you can copy a Paradox table to an existing database on a remote SQL server. For a complete description of the DBD, see Appendix A, “Using Database Desktop.” Delphi Client/Server enables programmers to develop and deploy database client applications for both desktop and remote servers. One of Delphi’s strengths is the ease with which an application developed for the desktop can be adapted to access data on a remote SQL server. The user interface need not change even if the source of the data changes. To an end user, a Delphi database application looks the same whether it accesses a local database file or a remote SQL database. For simple applications that use TQuery components to access desktop data, the transition to a remote server may be as simple as changing the data source. For other applications, more significant changes may be in order. Some of these changes are the result of differing conventions and concurrency issues between desktop and SQL databases. For example, desktop databases like Paradox and dBASE are record-oriented. They always display records in ascending or descending alphabetic or numeric order. They lock and access a single record at a time. Each time a user changes a record, the changes are immediately written to the database. Desktop database users can see a range of records, and can efficiently navigate forward and backward through that range. In contrast, data in SQL databases is set-oriented, and designed for simultaneous multiuser access. Record ordering must be specified as part of an SQL query. To accommodate multiuser access to data, SQL relies on transactions to govern access. For more information about working with transactions, see Chapter 6, “Building a client/server application.” Database application development methodology‌‌ Developing database applications with Delphi is similar to developing other types of software, but there are important distinctions and challenges that must be addressed. The methodology presented in this section should be used as a guideline that you can adapt to meet your specific business needs. Since an application’s design usually depends on the structure of the database it will access, the database must be defined before the application can be developed. Note Database development (also called data definition) is a part of the overall development process, but is beyond the scope of this manual. For more information, refer to the numerous books about relational database design. There are four possible scenarios for Delphi database application development: • The database does not yet exist or must be re-defined. • Use the Database Desktop utility to define Paradox and dBASE tables. For more information, see Appendix A, “Using Database Desktop.” • For SQL servers, use the tools provided with the server or the Database Desktop. For example, for the Local InterBase Server or an InterBase Workgroup Server, use Windows ISQL. For more information, see the Local InterBase Server User’s Guide and the InterBase Data Definition Guide. • The database exists on a desktop or LAN data source (Paradox or dBASE) and the database will access it there. If the BDE and the data source are on the same machine as the application, then the application is a standalone (not client/server) application. • The database exists on a desktop data source, and is being upsized to an SQL server. This scenario is discussed in Appendix C, “Using local SQL.” • The database exists on an SQL server and the application will access it there. This is a standard client/server application. For information specific to developing a client/ server application, Chapter 6, “Building a client/server application.” The goal of database application development is to build a product which meets end users’ long-term needs. While this goal may seem obvious, it is important not to lose sight of it throughout the complexities and often conflicting demands of the development process. To create a successful application it is critical to define the end users' needs in detail early in the development process. The three primary stages of database application development are • Design and prototyping • Implementation • Deployment and maintenance There are database and application tasks in each of these phases. Depending on the size and scope of the development project, the database and application tasks may be performed by different individuals or by the same individual. Often, one team or individual will be responsible for the database tasks of the project, and another team or individual will be responsible for the application tasks.‌ Design Implementation Deployment For client/server applications, the database and application tasks become more distinct, since they run on different platforms, often with different operating systems (for example, a Unix server and Windows 3.1 client). When development responsibilities are thus divided it is important to clearly delineate in the design phase which functions will be performed by the database server and which will be performed by the client application. Usually, the functional lines are clear cut. But database processes such as stored procedures can sometimes perform functions that can also be performed by the client application. Depending on the expected deployment configuration, application requirements, and other considerations, the design can allocate such functions to either client or server. It is also important to realize that database application development is by its nature an iterative process. Users may not fully understand their own needs, or may define additional needs as development proceeds. User interface elements are always refined as they are used. Also, changing business needs will change requirements over time. Generally, a number of iterations through the development cycle will be required before an application can meet a significant portion of its requirements. The design phase begins with requirements definition. In consultation with knowledgeable end users, define the functional specifications for the database and applications. Determine which aspects of the functional requirements will be implemented in the database design, and which aspects will be implemented in the applications. For client/server applications, often certain functions can be performed either by the server or by the application; for example, a complex mathematical transform function could be performed either by the client application or by a stored procedure on the server. The hardware deployment configuration will generally determine whether such functions are best performed on the server or client. For example, if the client platforms are expected to be low-end desktop PCs, and the server platform is expected to be a high-end workstation, then it will probably be best to run computation-intensive functions on the server. If the hardware configuration changes, then it is possible to move the function between client and server in a later iteration.‌ In the implementation phase, you use Delphi to build and test the application conceived in the design phase. During the implementation phase, you should use a duplicate data source, that is, a data source that has the same essential structure as the production database, but with a small subset of representative data. It is not recommended to develop an application against a production database, since the untested application may corrupt the data or otherwise interfere with normal database activities. If your application will ultimately be deployed to use a desktop data source, make copies of the required tables with the Database Desktop, and populate them with representative “dummy” data. If the application will ultimately be deployed to use a remote data source (an SQL server), then you can take two approaches during the implementation phase: • Develop and test the application against a non-production database on the Local InterBase Server. • Develop and test the application against a non-production database on the server. The first approach has the advantage that is isolated on the development platform(s), and so will not interfere with other server activities. It will not consume server resources or increase network traffic. Its primary disadvantage is that only standard SQL server features can be used and tested during this phase, if you are using a server other than InterBase for the deployed application. The second approach enables you to surface all server-specific features, but will consume network and server resources during testing. This approach can be dangerous, since it is conceivable that a programmer error could cause a server to crash during testing. In the deployment phase, the client/server application is put to the acid test: it is handed over to end users. To ensure that the application’s basic functionality is error-free, deploy a prototype application before attempting to deploy a production application. Since the ultimate judges of an application’s efficacy are its users, developers must be prepared to incorporate changes to applications arising from their suggestions, changing business needs, and for general enhancement (for example, for usability). Sometimes application changes may require changes to the database, and conversely, changes to the database may require application changes. For this reason, application developers and database developers should work together closely during this phase. As features and enhancements are incorporated into the application, the application moves iteratively closer to completion. Deploying a client/server application requires addressing a number of special issues, including connectivity and multiuser access. These issues are discussed in Chapter 6, “Building a client/server application.”‌ Deploying an application means giving it to the end users, and providing the necessary software they need to use the application in a production environment. Non-database applications require only an .EXE file to run—Delphi applications do not require a run time interpreter or DLL. Typically, when deploying a database application, you will create a package that includes all the files that end users need to run the application and access data sources. These files include • The application .EXE file and .DLL files (if any) • Required ancillary files (for example, a README file or .HLP files for online help) • BDE support for database access (desktop or server) • ReportSmith Runtime for running and printing reports • If the application uses VBX controls, include each VBX along with BIVBX11.DLL If you are distributing the files on disks, you will generally want to compress them with a standard file compression utility, and provide the utility on the disk. You may also want to build a simple installation application to install the files for your users. For complex applications, you may want to use one of the many commercially-available installation programs. For information on deploying support for remote server access, see Chapter 6, “Building a client/server application.” For client/server applications, you also must ensure that the necessary communications software (for example, TCP/IP interface) is installed on the client platforms. This software is provided with databases servers. For more information, see your server documentation. When you deploy a database application, you must ensure that the client platform has the correct version of the BDE installed. Delphi includes Redistributable BDE, with its own installation utility, that can you can redistribute with your applications. When you deploy an application, simply include a copy of the Redistributable BDE disk. The Delphi license agreement requires you to make all the files in Redistributable BDE available to your application users. This requirement enables users to install the new version of the BDE for Delphi without interfering with existing Paradox and dBASE applications. You can advise your users to save disk space and install only the drivers required to run your application, but you must still distribute all the files in the Redistributable BDE.‌ For example, if your application needs access only to Paradox files, you can advise your users not to deploy the dBASE driver. The minimum BDE configuration for accessing a Paradox database requires about 500 Kbytes. IDAPI01.DLL BDE API DLL IDBAT01.DLL BDE Batch Utilities DLL IDQRY01.DLL BDE Query DLL IDASCI01.DLL BDE ASCII Driver DLL IDPDX01.DLL BDE Paradox Driver DLL IDDBAS01.DLL BDE dBASE Driver DLL IDR10009.DLL BDE Resources DLL ILD01.DLL Language Driver DLL IDODBC01.DLL BDE ODBC Socket DLL ▇▇▇▇.▇▇▇ Microsoft ODBC Driver Manager DLL, version 2.0 ▇▇▇▇▇▇▇▇.▇▇▇ Microsoft ODBC Driver installation DLL, version 2.0 TUTILITY.DLL BDE Tutility DLL BDECFG.EXE BDE Configuration Utility BDECFG.HLP BDE Configuration Utility Help IDAPI.CFG BDE (IDAPI) Configuration File The BDE provides the ability to localize applications with language drivers. The language driver DLL loads the drivers specified by Paradox or dBASE tables or in IDAPI.CFG for server databases. The language drivers are files with extension .LD installed to the LANGDRV sub-directory of the BDE directory. [Borland Language Drivers] LDPath = C:\DELPHI\IDAPI\LANGDRV The BDE comes with an ODBC Socket. It has been certified with Microsoft’s 2.0 ODBC Driver Manager. If you have a different version of the ODBC Driver Manager: • Back up your existing ODBC.DLL and ODBCINST.DLL • Copy the version 2.0 files, ▇▇▇▇.▇▇▇ and ▇▇▇▇▇▇▇▇.▇▇▇, from your BDE directory to your WINDOWS\SYSTEM directory. • Rename these files to ODBC.DLL and ODBCINST.DLL. C h a p t e r‌ This chapter is a tutorial and introduction to building Delphi database applications. Examples show how to perform database tasks using Delphi interactively and by programming in Object Pascal. In each example you build a single form, self-contained and independent of the others. You can save yourself some work by doing the examples in sequence. Several examples use the same basic form as a starting point. Note This material assumes you know how to use Delphi; it tells you what to do to perform certain tasks. For more details (that is, to find out why), follow the cross-references in the “For more information” section that follows each example. In particular, see Chapter 3, “Using data access components and tools.” The tutorial consists of the following sections: • “Building forms” describes how to use the Database Form Expert to create database forms, including single-table and master-detail forms. It also describes how to enhance forms by adding components and code by hand. • “Working with fields” describes how to read and write field values, how to search for values and do table lookups, and how to format data displayed to the user. It also describes how to work with calculated fields. • “Using queries and ranges” describes how to use SQL queries and set ranges to select a subset of the data in one or more tables. • “Printing reports and forms” describes how to print ReportSmith reports and Delphi forms. The material in this section focuses on database issues. To learn about general application building with Delphi, see the User’s Guide. The forms described here are the basis for a database application called MASTAPP, designed to meet the record-keeping needs of the fictitious Marine Adventures & Sunken Treasures company (MAST).‌ MAST sells diving equipment and arranges diving expeditions. MASTAPP tracks information about customers, orders, inventory, and vendors. The tutorial starts with a simple “codeless” form for viewing and editing table data, and works up to a full-featured invoice form containing several tables, data-aware components, and other advanced Delphi features. All the forms, tables, and related files are installed by default in C:\DELPHI\DEMOS\DB\MASTAPP. During a default installation of Delphi, an alias, DBDEMOS, tha