paone@aramis.rutgers.edu (Phil Paone) (02/13/89)
I am getting the message "Invalid message type received from sqlexec process" The unusual thing about it is that I am running 2.10.00? on 4 machines, my 3B1, an Amdahl and 2 3B2/400s and only the 400s return the error on the same program. Does anyone have any solution on input? The details are as follows. I have a screen run by a cperfed program. If the user does an update and then gives any other database command ,the message comes up AFTER executing the command and displaying the results. Any Help is appreciated, Phil Paone attmail!ppaone -- Phil Paone attmail!ppaone !rutgers.edu!topaz.edu!ppaone paone@topaz.rutgers.edu
aland@infmx.UUCP (Dr. Scump) (02/14/89)
In article <Feb.13.09.11.38.1989.17699@aramis.rutgers.edu>, paone@aramis.rutgers.edu (Phil Paone) writes: > > I am getting the message > "Invalid message type received from sqlexec process" > > The unusual thing about it is that I am running 2.10.00? on 4 > machines, my 3B1, an Amdahl and 2 3B2/400s and only the 400s return the > error on the same program. Does anyone have any solution on input? > > The details are as follows. I have a screen run by a cperfed program. > If the user does an update and then gives any other database > command ,the message comes up AFTER executing the command and > displaying the results. > Any Help is appreciated, > Phil Paone Hmmmm... never seen that exact behavior before. Here are a few things to watch for, however: 1) Do you have a $database statement in your ESQL/C code (or C code; whatever it is you're cperfing). If so, *take it out and shoot it*! Before 2.10, a $database statement was required in a function to be called from the form's ON BEGINNING block; effective with 2.10 (when Perform started using the SQL engine), they will just cause you heartache. The reason I ask this first is that the printed cperf examples in the original 2.10.00 ESQL manuals show a $database statement and an ON BEGINNING block in the demo program listing where it no longer belongs; fortunately, the actual demos in the product properly omitted them. Some people who used the printed demo listings as examples got burned. 1a) is "cperfing" a word? :-] 2) are you *shore* that the form has been freshly recompiled and the ESQL/C code has been freshly cperfed? 3) are you using reserved words in any table, column, or host variable names? 4) with regards to the affected table (whatever the current table is when you run the failing update): a) have you specified all of the columns for that table? (it's not necessarily a problem if you didn't, but it could indicate that some changes were made to the code or schema and not to the form) b) is the "current table" a view? (There were several bugs with views in Perform in version 2.10.00 that were fixed in .03) c) are you doing anything naughty in AFTER EDITUPDATE or AFTER UPDATE blocks that pertain to that table or columns in that table? (Especially AFTER UPDATE) d) ditto for other AFTER blocks (and even ON BEGINNING) ? e) do you do a $close database anywhere in your ESQL or C code? I hope one of these turns out to be the problem. I've had a pretty good guess record on CPERF lately, and I don't want to ruin it :-]. Regards, Alan Denney (P.S.: except for the 3B1, why are you still using .00 instead of .03? Just curious) -- Alan S. Denney @ Informix Software, Inc. {pyramid|uunet}!infmx!aland "I want to live! -------------------------------------------- as an honest man, Disclaimer: These opinions are mine alone. to get all I deserve If I am caught or killed, the secretary and to give all I can." will disavow any knowledge of my actions. - S. Vega
allbery@ncoast.ORG (Brandon S. Allbery) (02/19/89)
As quoted from <Feb.13.09.11.38.1989.17699@aramis.rutgers.edu> by paone@aramis.rutgers.edu (Phil Paone): +--------------- | I am getting the message | "Invalid message type received from sqlexec process" +--------------- This is an internal error. Contact Informix Software, Inc. to see what can be done about it. (Last time I got this error, it was as a result of sqlexec dumping core....) ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser