dtF

A royalty-free relational database management system

By Jeff Fisher, SalesKit Software Corp.

About the Author

Jeff Fisher - Jeff works at SalesKit Software Corp. While looking around for a good database to use with their application software, they ran across dtF. Skeptical at first, he checked it out. Now he’s uses it and loves it. Apparently he’s not alone in how he feels about it. His former partner liked it so much he became the US distributor for it (dtF Americas).

Finally there’s a royalty-free relational database management system for Macintosh C/C++ application developers. The performance may surprise you, yet the library is small and requires only a few hundred K of RAM at runtime. It features SQL, full transaction control, error recovery, client server architecture and is optimized for the Macintosh. The new product is call dtF and was developed in Germany. Like German automobiles, dtF is well built and efficient in every aspect. Unlike German automobiles, dtF does not cost an arm and a leg.

Performance

Many SQL database management systems are just an SQL interface plopped on top of an ISAM record access system. Such a system can’t deliver the performance of a system designed from the ground up. dtF is a true set-oriented SQL engine designed specifically for optimum performance on personal computer architectures.

The performance of dtF is unequaled in our tests. We have clients who want to access large databases (>22,000 records) from a standalone version of our software. With our old database engine, queries that took more than five minutes now take less than thirteen seconds with dtF! I always hate performance comparisons because they never compare aspects relevant to my projects. There is really no substitute for doing your own tests. We compared dtF’s data access speed with 4D, Oracle, Inside Out, and FoxPro 2.5. We found dtF to be over eight times faster on multi-table ordered queries (an aspect relevant to our project) than the nearest competitor.

Client/Server

dtF implements a client/server architecture. It does not use file sharing to support multi-user table access over the network. The dtF server processes queries and sends only results to the client. This ensures high performance, efficient use of the network bandwidth, and data security. File sharing approaches place high demands on a network and the onus of doing lock management, deadlock detection, and error recovery on the application developer.

One interesting aspect of dtF is how it divides labor between client and server. Many client server systems assume a “dumb” client. This traditional approach creates a bottleneck at the server - not only does the server perform client requests but each time a user scrolls a list window the client must ask the server to send down more data. This can create a lot of unwanted network traffic as well as bog the server down with intermittent requests for data. The dtF server passes results to the client so no network traffic is generated when accessing results. This approach is ideal for modern network environments and puts your existing equipment to good use. The precious power of the server is reserved for processing transactions and the client can get right to the job of displaying results.

Both single-user standalone and client-server versions of dtF use the same client-server model and interface.

Stand alone applications with dtF can be converted to multi user client/server applications by simply adding three library calls to your code. This helps dtF offer a practical standalone interface, perhaps the only one for a Macintosh SQL DBMS.

Transaction Control

dtF supports true transaction processing. This is the only way to ensure data integrity. Consider an order processing application that requires one transaction to add the order and five more transactions to add line items to another table. If there is a network failure on the third line item, it is essential to abort the entire transaction. In such a case dtF would simply rollback the transactions and return the database to a state which looks like they never took place.

The current Macintosh version of dtF server can handle 63 parallel concurrent transactions with automatic lock management, automatic deadlock detection, and error recovery. With an ISAM record access system, you have to explicitly lock records and indexes when performing updates and deletes. Lock management and deadlock avoidance can become very complex when you have multiple related tables. For example:

/* 1 */
// must lock both tables to avoid deadlock

act_locked = bogus_lock(accounts);
cnt_locked = bogus_lock(contacts);

if (!act_locked || !cnt_locked )
 return errorDeadLocked;

bogus_use(accounts); // use the accounts table
if (bogus_seek (theAccountID))//  find the desired record
{
 bogus_delete(); // delete the account record
 bogus_use(contacts);// use the contacts table
 bogus_settag(“act_id”);
 if (bogus_seek (theAccountID))  //  find the desired record
 {
 bogus_delete(); // delete the account record
 }
}
bogus_unlock(accounts);
bogus_unlock(contacts);

On the other hand, all lock management and deadlock detection is done by dtF. Client/server applications require no special multiuser considerations. You don’t have to write anything similar to the above code.

Security

All data within a dtF database is encrypted and compressed. Tables requiring 22MB in another database management system took less than 4MB in dtF. Data encryption ensures that data cannot be pilfered, even with disk editors. Access rights are granted at the table level. Read, update, insert, and delete privileges can be set at the table level. Administration rights (create and delete tables and indexes) are also granted at the table level.

Utilities

dtF comes with a database administration tool and browser (written with MacApp) call dtFQuery.

You can use dtFQuery to:

• Import data

• Export data

• Issue SQL statements.

• Create databases with your own creators and file types

• Repair corrupted database files.

Compatibility

dtF supports a large subset of ISO standard SQL, and it is optimized for performance and ease of use on the Macintosh. dtF libraries are included for the latest MPW C/C++ and Symantec environments. I use dtF with MacApp 3.0.1 and TCL and have included a sample MacApp application [available on this month’s source disk and the online services - Ed stb].

API

Both the multi user and stand alone versions of dtF have the same C interface. This allows you to develop applications with client server architecture that will perform great in single user, single platform situations. Converting a single user applications using dtF into a multi user application is easy. Add three function calls to select a dtF server and relink with the multiuser object library.

There are two interface levels called simply Level 1 and Level 2. This provides the developer with two possible levels of abstraction and encapsulation. The Level 2 interface is a high-level, easy-to-use interface. The Level 1 interface gives you raw access to dtF. We use the high-level interface for all of our testing and development and have found no need to access the low level interface so far.

In our MacApp 3.0.1 application, we call 15 different dtF functions. A fully functional application could use as few as three: select database (or server), logon, and execute. While this seems almost too simple, remember that all operations are encapsulated in the SQL you submit to the server.

All memory used by dtF is allocated at startup, so you won’t have to struggle with intermittent low-memory conditions caused by the DBMS. And because it has its own virtual memory and caching system, you will never have to preflight queries. The virtual memory and caching systems can be optimized by adjusting values in a resource.

dtF is ideal for use with MacApp because it will not interfere with MacApp memory allocation and segment management schemes. Other database management systems require you to jump through a few hoops to fit in with MacApp. dtF requires no explicit call to initialize or shutdown, and you don’t have to provide idle handlers to dtF.

Why SQL?

An SQL database management system like dtF offers the developer a single interface for data definition, data manipulation and data administration. ISAM (Indexed Sequential Access Method) architectures aren’t as convenient for getting at your data (selecting indexes, filtering unwanted records, etc ). With an SQL database management system, you describe the results you want with the SQL statement and the database engine does the rest.

As an example, suppose that you are developing a contact management system and you want a list of the contacts with last name equal to “Smith” grouped by account name. The code required to retrieve the desired result from dtF is shown below.

/* 2 */
char theSQL[255];

strcpy(theSQL, "select * from accounts,contacts where
 accounts.act_id = contact.act_id and 
 contacts.l_name = 'Smith' group by
 account.act_name order by contacts.zipcode");

dtF2exec(theSQL);

   // now access the results which are already sorted

All you have to do is submit a simple SQL statement and dtF does all the processing.

The same query with a typical ISAM record access system would look something like the following.

/* 3 */
bogus_use(accounts); // use the accounts table
bogus_settag(“act_name”);
actRecNum = bogus_recordcount();

for (act_index = 1; act_index <= actRecNum; ++act_index)
{
 bogus_fieldstring(“act_name”,accountName);
 bogus_fieldstring(“act_id”,accountID);

 bogus_use(contacts);
 bogus_settag(“l_name”);
 cntRecNum = bogus_recordcount();

 bogus_seek (“Smith”)
 do     // look for hits
 {
 bogus_fieldstring(“act_id”,cntAccountID);
 if (strcmp(cntAccountID,accountID) == 0) // if account ids match
 {
 // we finally found one
 }
 }while (bogus_skip(1));

 bogus_use(accounts);
 bogus_settag(“act_name”);
 bogus_skip(1);
}

Or even worse.

/* 4 */
bogus_act_ref = bogus_open(accounts);// use the accounts table
bogus_cnt_ref = bogus_open(contacts);// use the contacts table

bogus_setbuffer(bogus_act_ref ,&bogus_act_struct); 
 // <<hardcoded structs
bogus_setbuffer(bogus_cnt_ref ,&bogus_cnt_struct); 
 // <<hardcoded structs

bogus_setkey(bogus_act_ref ,”act_name”);
bogus_setkey(bogus_act_ref ,”l_name”);

while (bogus_posvalid(bogus_ref,&bogus_struct))
{
 bogus_cnt_hardcodestruct.act_id = bogus_act_struct.act_id;
 
 // use up a bunch of memory building a result set

 bogus_do_find(bogus_cnt_ref,&bogus_cnt_struct)
 tempSet = bogus_build_set(bogus_cnt_ref ,bogus_cnt_struct);
 bogus_set_read(bogus_cnt_ref ,tempSet );
 bogus_sort_set(tempSet );

 // intersect result set with previous result sets
 bogus_intersection(resultSet,tempSet);
 bogus_skip(bogus_cnt_ref ,1);
}
   // finally use the result set to access selected records

This seems like an extreme example, but I’ve used a database engine that even required me to check to see if the current record was marked as deleted before using the result.

Cursors

When you are going to deal with queries which will generate very large results, sometimes it’s better to let the server keep track of the results, and then use a set of “cursor” calls to navigate through the results without needing to bring them all into the client’s memory all at once. A cursor is a reference into the results, and it can be used to index through the results. Developers familiar with DAL, ODBC, Oracle call interface, Sybase DBLib or any other SQL C programming interface are probably already familiar with this concept.

For an example, consider the large database that MacTech Magazine uses to keep track of its subscribers. The subscription guy needs to notify individuals who’s subscriptions will run out soon to help prevent them from missing a single excellent MacTech issue. He needs a subset of the total subscribers and he may also want them ordered by zip code (so he can save some money on postage). A cursor is an efficient way of producing the ordered subset without building a table in the client’s memory.

In a graphical operating system like the Macintosh, you may want several cursors, one for each list view or one for each window. For example, in a contact management application, you have a list of all available contacts ordered by last name. In another window, you might have a list of contacts with whom you have an appointment, ordered by appointment date. There could be thousands of contacts (my boss has over 6000 in his contact manager) and the query results might just be too big to hold in memory. If every window has its own cursor, each window can display different result sets from the appointments table at the same time. This is supported by a dtF concept called workspaces. Each cursor is referenced by a unique workspace identifier.

dtF allows forward and backward cursor movement. Some client server systems will only move forward or require you to build a result buffer in memory to move backward. Bi-directional cursor movement can really simplify your application.

Support

After using several different DBMS systems, we have amassed many support horror stories and were very concerned about using a database developed in Germany. We decided go to Germany and get the story first hand. dtF was developed by the Theta Group and I was very pleased to find out that they are true Macintosh fanatics. We have been developing with dtF for almost six months and have been thrilled with the support we have received. While all support is currently provided by the Theta Group, plans are well underway to provide support in the United States through dtF Americas, the new US distributor of dtF.

Future of dtF

Currently in the works are a multi user version using TCP/IP rather than AppleTalk, further performance optimization, and cross-platform support. An AppleScript extension using dtF is already available from Graphical Business Interfaces and many other third parties tools and applications will be available in the US by the printing of this article.

Conclusion

dtF is a relational database management system created by Macintosh developers for Macintosh developers. Efficient. Fast. SQL. Compact. Safe. We have examined all of the options and have chosen dtF and now you know why.

Pricing information: dtF Evaluation $129, dtF Macintosh SDK $695, dtf LAN Macintosh SDK $1595, dtf Server $1295.

For more information, contact dtF Americas, Inc. at 14720 Plumas Drive, Chesterfield, MO 63017. (800) DTF-1790 voice, (314) 530-1697 fax, AppleLink DTF.AMERICA.