Xref: utzoo comp.databases:7974 comp.sys.mac.hypercard:5114
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!batcomputer!munnari.oz.au!brolga!bunyip.cc.uq.oz.au!lance!kirk!cameron
From: cameron@kirk.nmg.bu.oz (Cameron Stevenson)
Newsgroups: comp.databases,comp.sys.mac.hypercard
Subject: Re: Accessing an Oracle database from the hypercard interface
Message-ID: <2650@kirk.nmg.bu.oz>
Date: 28 Nov 90 00:40:30 GMT
References: <1990Nov27.162424.6319@dhw68k.cts.com>
Organization: Network Management Group, Bond University, Australia
Lines: 54

From article <1990Nov27.162424.6319@dhw68k.cts.com>, by mrx@dhw68k.cts.com (Mark Murphy):
> In article <499@n5pph007.UUCP> you write:
>>
>>    Is this problem inherent in using the Mac's bit-mapped interface?
>>
>>    Has anyone else seen/worked through this problem?
>>
>>    Since we are mainly concerned with using a Mac interface (not 
>>       necessarily Hypercard), are there any other packages out 
>>       there that someone has experience with that can give the 
>>       Mac 'look and feel' but without the 25 sec time delay?..... 
> 
>    I have not worked with Oracle connected with SQL*Net before... I have only
> worked with the single-user stand alone version for the Mac.  Yet it seems to
> me that there should be no 25 sec time delay.  I have not seen any such delay
> in the demos I have seen at trade shows, seminars, etc.

Yes, you are right there. There shouldn't be that sort of delay through the
network. We have Macs connected to Unix workstations (running Oracle) with
Appletalk/FastPath/Thin Ethernet, using TCP/IP as the protocol. We have found
that even with the slow speed of Appletalk/LocalTalk we get only a 50% speed
degredation between local and remote data.

>    Are you designing your own HyperCard stack to access your data, or are you
> using the query stacks that come with Oracle?  If so, those are really slow in
> displaying the data after the query.  The reason for this is that HyperCard
> must create a new card, create any fields needed, then put the information into
> each field.  It is a very slow process.

Yes, this is a slow process, but very easy to get up and running. Oracle offer
another method with the supplied Application Builder stack. This is just as
easy to use, and doesn't require a card to be built each time a query is 
issued - obviously for standard queries. We used the Application Builder for
most of our data entry operations (making an assumption that Oracle would
supply a relatively bug-free system to get the data into the database :-). For
the actual application, I created cards from scratch, fetching the data into
HyperCard variables as per the following....

>    The fastest way to retrieve data from Oracle is to use the SELECT INTO
> clause.  Then use GET NEXT ROW... or for even faster access GET NEXT xxx ROWS.

What we did here though (as Oracle suggest in the documentation) is make two
select queries, the first counts the number of rows satisfying the query 
(SELECT COUNT(*) FROM...), and the second actually fetches the rows into local
vairables (each variable becomes a multi-line text variable for each column
of data from the query). This is fast (minimal traffic over the network), and
allows you to skip forwards and backwards through the retrieved data (put line
x of variable y into card field z). 

Anyway, just a few thoughts.... Good luck.

Cameron Stephenson                     ph +61 75 951220
Bond University
Gold Coast    Australia