ADVERTISEMENT

HyperCard Letters

By Kirk Chase, Editor

Databases views

Paul Whittington

I was astonished to learn from Mr. Joseph Terry, Jr. that the first “real” database has just arrived in the Mac world. I think Oracle Corporation also must be surprised to hear that they do not have a “real” database.

Mr. Terry writes, “Remember that those old guys and gals really DID know something.” As one of those old guys with over 15 years of experience in data processing (that shows you how old I am - I still refer to it as data processing), I have had experience with databases from mainframes to micros.

In both his letter in the January, 1991 issue of MacTutor and his article in the February, 1991 issue, Mr. Terry expresses his opinion that a network database model is the best type of database for “serious” database systems. I think that a more enlightened opinion is that each database model has its strengths and weaknesses, and that a database’s appropriateness is dependent on the application employing it.

In a hierarchical database, data is linked from parent to child with the constraint that each child can have only one parent. The limitation is that you can only arbitrarily traverse the database from top to bottom. This works well when all of your data has a one to many relationship and has very few levels in the hierarchy. For example, an order system might have an order header with name and address information. Each order header can then point down to a line item for that order. This causes no problems because the line item is meaningless without the order header.

Hierarchical databases have been around since the late sixties. Network databases became popular after the Data Base Task Group of the Conference on Data Systems Languages (CODASYL-DBTG) issued a report defining a data management system that supports a complete network structure (April 1971). Since Mr. Terry did a thorough job explaining the network database structure, I won’t repeat that here. The big advantage that a network database has over a hierarchical one is that a child record can have more than one parent record and that you can go up and down between children and parents to your heart’s content. The disadvantage is that it is real easy to get lost in the database if you are not careful.

The relational database model is based on research done by E.F. Codd. The model is based on the mathematical foundation of relational algebra, which gets into relations, domains, degrees, and tuples. A more easily understood description defines a relation as a table with columns representing fields and rows representing records. Many of today’s popular databases are built on the relational foundation. The strength of a relational database is in its ability to extract and combine data in many flexible ways. Its disadvantage has always been the processing overhead that it imposes.

The best use of a relational database is in situations where you cannot anticipate the end-user’s needs. A database with sales information is a great example of the need for a relational database. Marketing people love to aggregate data by weird demographic information.

Furthermore, no database product conforms exclusively to any one model. Even Mr. Terry refers to his product as a network database with relational extensions. Every database product on the market has “extensions” to take advantage of features from another model.

I think that when we talk about “serious” databases, we are talking multi-user, client-server stuff. Mr. Terry should look at the Database Access Manager for System 7. This is going to have a huge influence on how applications access databases. It also defines how a database server must look to its clients and, more specifically, how Macintosh databases must look to applications.

(And now a word from our sponsor.)

For the past two years Griffin Software has had two database engines for the Macintosh that use HyperCard as a front end. HyperHIT is based on the hierarchical database model with a few whiz-bang extensions thrown in. HyperHIT-R is based on the relational database model. Both are available now through our publisher, SoftStream International, Inc. Currently in beta is the multi-user version which supports both HyperHIT and HyperHIT-R files. The expected release date for HyperHIT-N is the month of April.

Both HyperHIT and HyperHIT-R were designed with HyperCard in mind. They don’t have fixed length fields. They store data, except for sounds and pictures, as ASCII text, just as HyperCard does. HyperHIT-R allows for dynamic modifications of the database structure, without using separate utility programs (importData and exportData are two of the XCMDs). HyperHIT-R also allows for those bizarre queries that those marketing people think up. (Can you tell which users give me the most sleepless nights?) Such as, “all of the people in Illinois, Indiana and Iowa who have purchased the book DRUG USE IN THE WORKPLACE but have not purchased the book BODY FLUIDS”.

We would appreciate the opportunity to present an article showing our products’ strengths, as you have afforded to Mr. Terry.

[You are perfectly welcomed and urged to submit an article on your product. In today’s world, even small products must be strong to compete. Many people have turned to different aids to help them get more “bang for the buck”. Products like yours, Mr. Terry’s, MacApp, etc. are all out there for developers to use. Only desperate developers, though, purchase products they know little about, they do so in hopes the products will aid their effort. It is therefore imperative to have products reviewed and advertised.-ed]

Listing Correction

Kirk Chase

The header file “CRemoveLFApp.h” was inadvertently left out of Wade Maxfield’s article, “Designing With Objects” in the January 1991 MacTutor. Below is the listing.

/* 1 */

/*****
 * CRemoveLFApp.h
 *
 * Application class for a typical application.
 *
 *****/

#define _H_CRemoveLFApp   /* Include this file only once */
#include <CApplication.h>

struct CRemoveLFApp : CApplication 
 {
 /* No instance variables */

 void IRemoveLFApp(void);
 void SetUpFileParameters(void);
 void DoCommand(long theCommand);
 void Exit(void);
 void CreateDocument(void);
 void OpenDocument(SFReply *macSFReply);
 void Run(void); /* override of built in method */
};

Strip Style FKEY

Thomas Nielsen

Lately, I’ve found myself repeatedly frustrated by the simple operation of copying and pasting text in HyperCard 2.0. The problem occurs when I go to paste the text. It seems that HyperCard (many other applications) now copy the style of the text as well as the text itself. This is great until you have to go to the different menus to set the font, size, and style. Here is the code for a short little FKEY that strips away the style from the scrap, leaving only text.

/* 2 */

Handle NewClearSysHandle(long size){
 asm{
 move.l size,d0
 NewHandleCLEAR+SYS
 move.l a0,d0
 }
 }
 
void main(void){
 long scrapsize, offset;
 Handle h;
 
 scrapsize=0L;
 h=0L;
 if (!(h=NewClearSysHandle(0)))
 goto returnpoint;
 scrapsize=GetScrap(h,’TEXT’,&offset);
 if (scrapsize>0){ 
 SetHandleSize(h,scrapsize+(scrapsize &1)); /*make Handle even size*/
 ZeroScrap();
 PutScrap(scrapsize,’TEXT’,*h);
 SystemEdit(3); /*  Tricky part */
 }
returnpoint:
 if (h)
 DisposHandle(h);
 }

See the call to SystemEdit(3)? Well it took me FOREVER to figure that one out. The system won’t recognize that the scrap has changed until you do it. I hope I’m not the only programmer out there that’s had problems with this one!

For Think C project

 Project type->Code Resource
 Type:  FKEY (all capitols)
 ID:  7 (this is also the number key that invokes FKEY)
 Attrs:  20 (purgable)
 File Type:  rsrc (ResEdit)
 Creator:  RSED (ResEdit)
 Name:  Strip Style FKEY

[The full project and listing are included in this month’s source disk.-ed]

Multi-user AppleTalk For HyperCard

Kirk Chase

Epsi Computer Systems, Inc. has announced epsiTalk. This is a development tool for adding AppleTalk support for HyperCard 2.0. Using epsiTalk, you can incorporate distributive processing and file serving among network stations. This makes it ideal for work groups, conferencing, and multi-user applications. There are two versions, epsiTalk and epsiTalk-EZ selling for $175 and $395 respectively.

EpsiTalk has the ability of creating quick, distributive processing by allowing you to control other epsiTalk entities on other, idle Macintoshes. It comes equipped with tools for handling file transfers and access. EpsiTalk also supports aborting and clearing transmissions midstream.

For more information, contact Robert Eppich or Randy Young at

Epsi Computer Systems, Inc.

209-1255 56th Street

Delta, British Columbia V4L 2B9

Canada

(604) 943-8664