Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!rochester!rutgers!att!ulysses!sfsup!jdt From: jdt@sfsup.UUCP (Happy Informix User) Newsgroups: comp.databases Subject: Re: Strange problems with Informix Perform Summary: manuals and form compilers silent about many things Keywords: Informix perform nohangup? Message-ID: <4768@sfsup.UUCP> Date: 7 Feb 89 20:40:56 GMT References: <34891@codas.att.com> <4723@sfsup.UUCP> <130@attibr.UUCP> Reply-To: jdt@sfsup.att.com Organization: AT&T-BL, Summit N.J. USA 07901 Lines: 64 In article <130@attibr.UUCP>, mjm@attibr.UUCP (Mike Matthews) writes: > >I write: > > Perform is a strange beast. Seems to handle boundary conditions very poorly. > > I suspect there are fixed size tables for user functions, lookups, etc; when > > you exceed them unpredictable things start to happen! I have seen perform > > screens stop functioning when a new user-defined functions were added; also > > seen lookup's fail to work when a screen had too many of them. Never took > > the time to diagnose exactly when these things stop working. > Perform will not allow lookups of more then 12 tables which is described > in the 2.10 manual. We were definitely looking up less than 12 tables. 12 fields? I dunno. Besides, it's not in the 3.3 manual. Not much is. > Perform and Ace have definite limits that neither compiler ( saceprep or > formbuild ) are intelligent to warn about. The after effects can be quite > painful and often do not appear until later versions are installed. > We had a Perform application where a programmer had ignored the above mentioned > limit but the application ran any way until the Informix version was upgraded. > The perform screen started exhibiting the same behavior as described in the > HUPCL problem mentioned, essentially bringing a 3B2 to it knees, much to the > surprise of the system administrators doing the upgrade. I find the causal relationship here suspicious, but with Informix, who knows. > An ace report that results in a row greater than PAGE_SIZE - > ( 32 + 4 ) will bomb with any one of many strange messages. Why can`t saceprep > tally the row size and produce a warning giving a clue to the subsequent > run-time problem? I would assume that the form compilers and the form interpreters were written be separate groups to a given design spec...unfortunately, one or both of them took shortcuts and imposed undocumented limitations on the language. > > Also, never could get ESQL to work from within sperform. Had to run SQL > > calls in a child. Is this a feature or a bug? > The perform language is explicitly defined in the manual. I don't think > any extra-language constructs or references are supported. Don't you have > any manuals??? Have you ever attempted to develop something with Informix, or are you just some kind of tech support parrot who keeps saying "RTFM"? Well, let me tell you, I have full Informix 3.3/SQL/4GL manuals, and even so, you tend to get beyond what they cover pretty easily. As for the above, you obviously do not understand the question I am asking. I said 'sperform', not 'perform screens' or 'forms' or '.frm files' or whatever you care to call them. We wished to execute certain DB operations in our C functions called from the form; however ESQL wouldn't work. You DO know that you can link your own C functions into [s]perform, right? Haven't YOU ever done this? Check your manual... > Mike Matthews > ATT International > Tech Support I don't need you telling me RTFM; I can always get that from Informix! :-) John Tais AT&T-BL Summit NJ jdt@sfsup.att.com P.S. I DO like Informix. Honest.