New Era, superTable problems

Hi, I have some problems with the informix NewEra version 1.10WC1 on the microsoft windows platform. These problems are related to the supertable object. Maybe somebody out there has encoutered the same problems (errors ?). 1) If I return from the the event handler "beforeRowApplied" with FALSE, New Era executes the "afterRowApplied" event handler. That's not the correct behaviour in my opinion because the manual states: -- part from new era manual ******************************************************************** EVENT beforeRowApplied() RETURNING BOOLEAN EVENT afterRowApplied() RETURNING BOOLEAN These events are called just before and just after any changes to the row are applied to the database during calls to apply(). Application of the current row (and all remaining rows) can be prevented by returning FALSE from the event handler for the beforeRowApplied(), in which case afterRowApplied() is never executed. If either event returns FALSE, the apply() call will return FALSE as well. -- end of part ********************************************************************************* -- part from test sourcecode ******************************************************************* HANDLER customerST::Window1_SuperTable136_afterRowApplied(theRow ixRow) RETURNING BOOLEAN VARIABLE ok BOOLEAN LET ok = messageBox(NEW ixString("Info"), NEW ixString("afterRowApplied")) RETURN TRUE END HANDLER HANDLER customerST::Window1_SuperTable136_beforeRowApplied(theRow ixRow) RETURNING BOOLEAN VARIABLE ok BOOLEAN LET ok = messageBox(NEW ixString("Info"), NEW ixString("beforeRowApplied")) RETURN FALSE END HANDLER -- end of part ********************************************************************************* The "afterRowApplied" handler is always executed, no matter what beforeRowApplied returns. 2) I work with supertables using pessimistic locking. My transaction begins in the event handler "beforeRowLocked". That works fine, but if I call the member function "superTable.revert()" (reverting the modi- fied row to the original value) a second attempt to alter this row doesn't raise the "beforeRowLocked" event handler. The row is not locked (I checked it with "onstat -k"). 3) When working with the native database interface (no odbc-connection) I try to check the SQLCA.SQLCODE variable in various situations. In most cases it doesn't work, it's simply "0" regardless of a previous error. The isam error code variable SQLCA.SQLERRD[2] is not "0". It contains the right error code. For example an attempt was made to insert a duplicate value in a unique key column. Displaying the values of sqlca.sqlcode and sqlca.sqlerrd[2] in the "afterRowapplied" handler shows: sqlca.sqlcode -> 0 sqlca.sqlerrd[2] -> -100 -- part from test sourcecode ******************************************************************* HANDLER ixSuperTable::Window1_customerST_afterRowApplied(theRow ixRow) RETURNING BOOLEAN VARIABLE ok BOOLEAN -- in attempt was made to insert a duplicate value in a unique key column -- sqlca.sqlcode is "0" and sqlca.sqlerrd[2] is 100 LET ok = messageBox(NEW ixString("Info"), NEW ixString("sqlca.sqlcode -> " || sqlca.sqlcode)) LET ok = messageBox(NEW ixString("Info"), NEW ixString("sqlca.sqlerrd[2] -> " || sqlca.sqlerrd[2])) RETURN TRUE END HANDLER -- end of part ********************************************************************************* Any help, support-tip or hint would be greatly apprecitated. Wish you a nice weekend. -- ------------------------------------------------------------------------------------------------ Eric Herber Garmhausen AG, Germany Phone: +49 228 9551-687 Fax : +49 228 9551-686 Email: 100667.704@compuserve.com ------------------------------------------------------------------------------------------------