How to use databases with other applications. (Compute's Getting Started With: Databases)
by Tom Campbell

One of the more perilous questions of recent years has been, How do I use may database with other applictions? File translation has been iffy, and DOS has never supported any kind of interprogram data communication standards. Windows changes all of that.

Greatest Common Denominator: OLE

By far the most reliable means of connecting documents from different applications is to use OLE objects. For example, suppose you have a field named Comments in a Paradox table you send to your field offices every month. You note comments using Mircosoft Word for Windows and then use the Windows Clipboard to copy and paste them into the Paradox table every month. One month, you get two complaints from one of your biggest customers, and in your nervousness you forget to paste the changes into the database. Last month's stale data is there instead. Your field offices aren't alerted and screw up again. Next month, you'll probably remember to copy and paste, because you've just lost a great client!

A much better solution would be to use an OLE field in your Paradox document. Paste the document in just once, and Windows will handle maintenance for you from then on. Anytime the WinWord document changes, Windows--not you, and not Paradox--will take the responsibility of updating your Paradox table for you. What's most amazing is that the programmers creating the applications just need to know how to support OLE. They don't need to know anything about the product that created the OLE data. So any application that knows about OLE will support all other applications that know about it.

A little jargon is in order here. An application that can receive OLE data, as Paradox does in the example above, is called an OLE client. An application that creates the OLE data and can let other applications manipulate it is an OLE server. Paradox, for example, is an OLE client (hurray!) but not an OLE server (boo!).

Not So Bad: Copy and Paste

If you don't know how to use the Windows Clipboard, stop reading this article, stand up, and spank yourself. As a time-saver and for elimination of errors brought on by duplicate data entry, the Clipboard is worth the weight of your Windows manuals in gold. In general, the Clipboard works like this. Select something (by dragging the mouse in a Windows database, spreadsheet, or word processor, for example). It will be highlighted in reverse text, usually white on a black background. Choose Copy from the File menu. The Clipboard will have an invisible copy of whatever you've chosen. Now pop into another application and choose Paste from the Edit menu. A copy of the items you've selected will appear in the new application.

What's going on under the hood is much more interesting than this seemingly trivial example shows. The Clipboard can actually hold many different representations of the same data object simultaneously. If you copy cells from your Excel spreadsheet and paste them into Paintbrush, they'll appear as a bitmap. If you paste them into Word for Windows, they'll appear as an OLE object. If you paste them into Notepad, which doesn't support OLE, they'll appear as delimited text. That's because Excel has courteously registered the cell values you've copied in each of those formats. Most database managers stop at saving values as text, but that's plenty for most uses of the Clipboard.

While the Windows Clipboard is an honorable way to trade small amounts of data among applications, if you do it routinely, get OLE to do the job for you--not so much because of its minimal time improvement, but because it lets you adhere to the cardinal rule of database management: Never duplicate data.

Least Common Denominator: File Formats

For years now, any database worth its salt has been able to import dBASE files and Lotus 1-2-3's WKS spreadsheet files. This is important if you're moving to a new database manager--in which case the old one can probably export one of these formats--or if you need to get database information from a nondatabase application. Many Windows databases won't act as either OLE clients or OLE servers, so you'll have to rely on importing data files. DOS doesn't have OLE, of course, so you'll need to use translations there as well. You need to know whether your dBASE files use memo fields (see the glossary). Most applications don't know how to read or write them.