tpg@n5pph007.UUCP (Peter Graham) (11/21/90)
We are beginning work on a large Oracle-based system that we want to front-end
on the Mac using Hypercard. The databases itself will be running on an HP
unix machine, with the access from the Macs being through SQL*Net. The
problem is that we are seeing a 20-28 second delay on EVERY database access.
The bottleneck doesn't seem to be on the HP end...the data is being
sent to the Mac with little to no delay. There then seems to be some kind of
hangup in Hypercard. This delay occurs regardless of the type of access or the
amount of information returned. I have several questions:
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
realize that Oracle is supposed to come out with a Mac-based
version of SQL*Menu and SQL*Forms, but we need to be able to
display more than 80 columns.
Any advice would be greatly appreciated.
-------------------------------------------------------------------------
reply to: ...!mcnc!rti!n5pph007!tpg
NTI may care what I say, but I'm not
saying it for them...these opinions
and statements are mine entirelykraig@biostr.biostr.washington.edu (Kraig Eno) (11/22/90)
>front-end on the Mac using Hypercard. The database itself will be >running on an HP unix machine, with the access from the Macs being >through SQL*Net. I cannot tell you how to solve your problem, but I can offer some hope in a general way. We decided against Oracle because it was too expensive (not free, I mean) and too huge and complex on the Mac end. I've rolled my own with the following pieces: HyperCard (and SuperCard) running the MacTCP XCMD's to access a Sybase SQL database on a NeXT via TCP. Very similar to your situation but with different products. If I click on a button which requires data, I start seeing results in well under 2 seconds -- that includes composing the SQL command, sending it to the Unix database server, executing it, and getting the first row of results back in my HyperCard field. Small rows come back at a rate of about 3 per second, though that has not been optimized at all yet. So the problem is not inherent in the Mac interface. There MUST be a solution. If you can get Oracle data from a C program on your Unix machine, then I am sure that our method would work for you, but you may not want the pain. (I had to write a TCP-accessible daemon on the Unix side which fields requests, does the queries, and sends the data back. Easy once you know how, but hard to figure out!) Kraig Eno, kraig@biostr.washington.edu "Problems generate new knowledge." -- M. Usui
bc@Apple.COM (bill coderre) (11/26/90)
In article <499@n5pph007.UUCP> tpg@n5pph007.UUCP (T Peter Graham) writes: |We are beginning work on a large Oracle-based system that we want to front-end |on the Mac using Hypercard. The databases itself will be running on an HP |unix machine, with the access from the Macs being through SQL*Net. The |problem is that we are seeing a 20-28 second delay on EVERY database access. |The bottleneck doesn't seem to be on the HP end...the data is being |sent to the Mac with little to no delay. There then seems to be some kind of |hangup in Hypercard. This delay occurs regardless of the type of access or the |amount of information returned. I have several questions: | | Is this problem inherent in using the Mac's bit-mapped interface? Definitely not. It may be the fault of the Hypercard handlers "catching" the data, or it may be the overall design of the data pipeline. There might also be some kind of network problem, but in general: the Mac can do very quick TCP, via a Hypercard interface. Hypercard can receive fairly large (30K) chunks of data and deal with them quickly. | Has anyone else seen/worked through this problem? As a contractor to Apple, I used Sybase's HyperDBLib product for similar purposes. It was not without its drawbacks, but it did the job much faster than yours. In particular, it shipped back data one element at a time. So if a query generated, say 100 rows of 10 elements each, the response might take 100 seconds. Sybase told us that they were working to eliminate this bottleneck. Our workaround was not to ship thousands of elements. another workaround was to ship the data back as an ascii image (1 element) and then reparse it at the Hypercard end. Almost as slow. I suggest you find the person who wrote your Hypercard interface to the network (it might be an Oracle package, or something custom) and talk to them. It might be possible to change the interface protocol slightly and drastically speed things up. It might also be possible to take some chunk of Hypercard (for example, an input parser) and have it written in C as an "XCMD" that Hypercard can call. That definitely will speed things up, if you pick the right things. I also suggest you call Oracle Tech Support to get them to give you help with your specific problem. If they can't help, they might at least be able to point you at other people who have done similar things. The info in your letter isn't specific enough to pinpoint the problem, and I haven't worked with Oracle's package. Having written several Hypercard front ends for databases myself, I can assure you that it is indeed a fine idea to use Hypercard. It's usually fast enough to code the entire UI, can handle almost any necessary computation quickly enough if you are clever, and is easy to test, modify, extend, and customize. You could make an extremely friendly "intelligent database editor", for example, displaying the data in human-friendly format, decoding all your flag fields into radio buttons, checking user input for consistency, and providing "human readable" printouts, all with a minimum of SQL, in about 50 or 60 pages of Hypertalk. Adherence to a few simple rules will ensure that your front end is about as quick as possible: 1 Minimize data exchange with the host 1a make sure each query returns the minimum it can 1b never use two queries when you can join 2 Use OOP style coding practices. 2a put your database communication code into one script 2b isolate your interface to the host 3 Use quick algorithms instead of code tweaking 4 placate the user 4a only perform long operations when users expect them 4b use user feedback devices to tell how much longer 5 Don't do extra work 5a the host can usually do the work much faster than HC 5b if you work hard to add an extra feature that isn't used, rip it out. The code I wrote, a scheduler (ala chron), used custom hypercard editors to access the databases on a Sun running Sybase, via Transact/SQL and HyperDBLib. Even when the databases contained a lot of records, response time was reasonable, even on a Mac Plus. On any II-class machine, the response time was almost as good as a custom C application, and I was able to test my stuff with users on a day-to-day basis. While I don't think a Hypercard front end would work for situations where thousands of records must be processed at the Mac end, even then Hypercard would make an excellent test-bed for ideas and interfaces, which would then be handed off to a C programmer as a project spec. bill coderre private consultant, not apple sposkedroid, today
mrx@dhw68k.cts.com (Mark Murphy) (11/28/90)
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 > realize that Oracle is supposed to come out with a Mac-based > version of SQL*Menu and SQL*Forms, but we need to be able to > display more than 80 columns. > >Any advice would be greatly appreciated. > 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. 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. 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. If you are already directing the query results into local variables and have this time delay, I think it is time to call Oracle Tech Support. Make sure you get someone who is familar with the Mac... there are so few of them around! -- mark mrx@dhw68k.cts.com
cameron@kirk.nmg.bu.oz (Cameron Stevenson) (11/28/90)
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
descalan@bbn.com (David Escalante) (11/30/90)
In article <2650@kirk.nmg.bu.oz> cameron@kirk.nmg.bu.oz (Cameron Stevenson) writes: > From article <1990Nov27.162424.6319@dhw68k.cts.com>, by mrx@dhw68k.cts.com (Mark Murphy): > > In article <499@n5pph007.UUCP> you write: > >> > >> 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 tried replying to this via email, but it bounced, so I'm posting.... We are developing a "mission-critical" application using either Oracle for Hypercard/SQL*Net or SequeLink for Hypercard (from techGnosis), and so far our performance tests against a VAX 8700 using localtalk and a fairly complex Oracle database (thousands of records, dozens of tables) show GREAT response times, in the order of 1-2 seconds per query. This is not a Mac or a Hypercard limitation that is causing the problem. Nor is it a fundamental network issue, since we're getting about the same results via TCP/IP or Appletalk, localtalk or ethernet. Rather, it's probably in the way you're coding, as suggested by other posters. If you do a "select ... into ... from ... where ...", then "get next rows", it should work just fine. If you are using prototype cards or something, it will be much slower. ------------------------ David Escalante Internet: descalan@bbn.com Applelink: N0608 UUCP: {backbone}!bbn!descalan