next »

[.]

Hi,

I'm getting a strange error with Genero 2.21.02 when reading from a table, but against the same instance of Informix IDS with the same database setup in fglprofile and against the same database it works under 2.11.10. This is an internal Informix error that you shouldn't see but it only appears with 2.21.

Could not position within a table (jeffm.pat_nhs_data).
SYSTEM error number -770.
Bad fragment id specified.

The same piece of code also works elsewhere in the system.

Any thoughts?

(Table stru

[Stephen T.]

Morning Jeff,
Not sure if this is relevant, but is that a 770 with SQL 243? It's just that I've had that error on V1 and V2 Genero - but it is an Informix problem in V9.4 IDS - the error can be either:

bug_number      155781
description     REOPTIMIZATION OF A SELECT AGAINST A VIEW THAT CONTAINS A UNION RESULTS IN ERRORS -243/-770 (T
EMP TABLE FOR VIEW).
product_code    ONLINE
component_code  SQL

OR
bug_number      162668
description     EXECUTING A PREPARED STATEMENT JOIN WITH A VIEW MAY FAIL WITH -243/-770 IF A COMMIT/ROLLBACK WAS DONE BEFORE EXECUTING IT THE FIRST TIME
product_code    ONLINE
component_code  SQL

The times I had it (still get it), it was whereI had a prepared cursor with a join (ie 162668).
I tried putting other 'dummy' statements in between the commit and the cursor, but no joy. The next step was to 'un-prepare' the cursor - but a move to v10 ids looked imminent, so that wasn't tried.

Maybe of help to you.

[Sebastien F.]

Hello Jeff, (thank you Stephen for your reply)

Are you 100% sure that the error does not occur with Genero 2.11 ?

While there are good chances that your problem is an Informix bug, it's not impossible that Genero 2.21 introduced a memory corruption (in a particular case we don't QA) that confuses the Informix client and produces this error -770...

To be sure, and if you can provide us with a sample that reproduces the error, we can execute it here in house with a memory checker... If you have Linux you can do it yourself with a tool named valgrind...

Another option that I often use to make sure it's an Informix bug is to write the equivalent ESQL/C program doing the same SQL statements as the 4GL program. Of course this is not easy if the 4GL program is complex so first you should try to reduce the code that raises the error...

I guess you are not using new features introduced in 2.2x such as a the Java interface, since you execute the program with 2.11, right?

May I suggest to install an intermediate version (2.20) to see if you reproduce? If the error occurs only with 2.21 and not with 2.20 that is an important information.

What version of the Informix CSDK have you installed?
I would also suggest to install the latest version to see if it fixes the issue.

Seb

[.]

Hi Seb,

I am 100% sure. Not only that but the same code, opened using the exact same passed parameters works fine in a different application. It also happens against 2 seperate IDS databases so it can't be a corruption issue.

Neil Martin from the UK was here on Tuesday and saw it and was fairly sure that this looked like a memory issue.

Also, if I put a statement to call a function (disp_message) to display a line of text just before the foreach that causes this problem, in the working application this shows up fine but in the failing application it locks up the application and you need to kill it.

I hope that this feedbak helps (though not sure how!). Really not sure how to recreate this as it seems specific to the application. Long term this won't be running on the same server, or against IDS but we're waiting on the DB team before we can migrate our applications across to Genero DB so this is our best way of moving our applications up to 2.21 needed for Genero DB.

Thanks

Jeff

[Sebastien F.]

Jeff,

Ok so this looks like a memory corruption to me too.

At this stage I strongly suggest that you contact the regular support channel to follow up.

If you provide OS details we can certainly provide a debug version of fglrun, .

Then if it's Linux I would use valgrind to check memory bounds.

Is the failing application using a lot of resources? (many forms, SQL cursors, large static arrays, etc)?

Seb