Re: Question about JAM

From: Tony Byorick <tonyb_at_access1.digex.net>
Date: 24 Jun 1994 14:13:38 GMT
Message-ID: <2uepmi$9go_at_news1.digex.net>


In article <2tfbpb$8nf_at_access1.digex.net>, daibach_at_access1.digex.net (David P. Mowry) writes:
|> We are currently using SYBASE on a SUN network under UNIX and Open Windows.
|> We are investigating possible GUI interfaces/app generators to use with
|> this and for other applications on the net.
|>
|> We've looked at Unify/Vision and are installing an evaluation copy
|> of the latest version of JAM.
|>
|> Has anyone out there had any experience with JAM and do you have any com-
|> ments (pro or con)? You can post answers here or e-mail to me.
|>
|> Thanx in advance.
|>
|> +--------------------------+-------------+
|> | daibach_at_access.digex.net | Olmaz olmaz |
|> | David P. Mowry | |
|> +--------------------------+-------------+

I recently worked on an effort that used JAM to develop an interface to Oracle databases. JAM is as good as any other GUI development product -- it has its good points and its bad. I'm sure you heard all the pros from the sales folks. The cons, for us, were few but significant:

  • A JAM interface does not accept/capture keyboard interrupts once the user sends it off to interact with the database. In other words, there is no CTRL-C to cancel or interrupt the transaction or query if the user changes his/her mind or realizes they made a mistake. This got us a LOT of complaints. I asked one of their technical engineers about it and all he would say is that it's a result of how they open their input stream. He said they have heard the complaint before, but they have no plans to change it.
  • We were not able to pass parameters into the JAM interface if we were using their rapid-protyping language (JPL).
  • The JAM error handler is not terribly robust about returning lots of information to the application. For example, it will tell you provided an incorrect column name, but it doesn't tell you which one is the source of the problem. The same tech engineer indicated that working on their error handler was a low priority for them.

Hope this helps. Good luck.

                                Teresa Larson

+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| Teresa A. Larson - Hughes STX Corporation                            |
| NASA/GSFC Code 933.0                        voice:  (301) 286-7867   |
| Greenbelt, Maryland  20771                  fax:    (301) 286-1777   |
| Teresa.Larson_at_gsfc.nasa.gov                                          |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
 
Received on Fri Jun 24 1994 - 16:13:38 CEST

Original text of this message