I'm using Baan IVc4 and have just created a new form. After making several changes to the form, I try to Edit Form one last time and receive the error:

Index 267 out of dims (266), Can not continue in ottadvformedit.

Baan tells me the form is corrupted and cannot be saved.

Does anyone know of any way to save the form? I have a valid dump - as my last version of the form does run in the session.

I am running Informix.

Thanks - Denise

Denise,

The changes you made might have corrupted the form. Make sure you pay attention to the location of the indexed field. Also check for single and multi-occurence fields. You can try renaming and detaching your form, copy another form from standard and modifying it one step at a time - dumping everytime you have a change.

...Remove the object on the unix level and replace it with your dumped copy.

I am still trying to figure out why a corrupt form would produce an 'out of dim' error though.

Doesn't seem to make sense, so there might be an additional problem.

I have an 'fssto159m00012' file, but not an old one. Where would the 'dumped' verison be?

Denise

Denise,

Not sure if this is your problem, but we have had this before in both forms but mainly reports. We couldn't find the solution for the form, so had to delete and recreate it. But in the report, it was because we had to many 'input fields' and had to delete some. I don't believe that was our problem with the form, as the 'form fields' option, should never have 255 fields (unless you have a very big form with lots of little fields).

Sounds like you may have to delete and re-create your form (hopefully you haven't made to many changes)...

I also had such a problem in the past. In my case problem was lying in frames and boxes I've drawn on the form. Somehow records in table ttadv304 got corupted. Field ttadv304.layout contains a string witch is responsibe for boxes, lines etc. The string is made of visible chars and some control codes. I think that form editor analyzes that string, extracts substrings visible on form and their positions. If the string is gone corupted, form editor gets too big substings or position numbers and blows up.

So, I used GTM to delete records from ttadv304 matching my form name , VRC , language and then form editor started succesfully. I had to redraw some things again, but i didn't have to recreate whole form.

You can try this before you delete the form and start design it again.

I deleted the ttadv304 record. I thought this was the miracle fix I was looking for.....but, it didn't work. Thanks, and I will remember this one if it happens again.

Thanks!

Denise

Hi Denise,

We faced a similar situation where the reports would not compile and gave fatal errors. We spent a lot of time with BaaN Tech and Support to resolve it.

After all the investigation we found the solution.

BaaN recommends the NLS settings as

nls_lang:american_america.we8iso8859p1

You can check your current settings from -

Here is the NLS settings from the oracle end.

>env | grep NLS
NLS_LANG=american_america.we8iso8859p1
ORA_NLS33=/app/common/oracle/product/8.1.7.2/ocommon/nls/admin/data

env is your binary or setbse program which sets your baan environment settings. the NLS_LANG is set by the set_oraenv. Easy way to identify in our case was that the NLS_LANG was AMERICAN_AMERICA.US7ASCII.

and also check the entry in db_resource -

"db_resource" 8 lines, 206 characters
dbsinit:01
ora_max_array_fetch:5
ora_max_array_insert:5
nls_lang:american_america.we8iso8859p1
nls_sort:binary
oracle_home:/app/common/oracle/product/8.1.7.2
ora_temporary_tablespace:TEMP


Here is the case and solution info -


The report compilation problem occurs because of wrong data in the table ttadv335. For these reports the symbol Ÿ is missing at the end of the data in the Layout field.
The solution to the problem is to delete this data in the table ttadv335 for that report. Compile the report and then edit the layout according to the requirements. This has to be done manually for the reports that come up with this error.
Currently, we do have any information how this kind of data gets into the table.

Fatal error: ttadv335.layo is a binary field with known issues on Oracle and NLS_LANG setting as per solution 1955. Need to verify if these individual reports listed in the case comments can individually maintain layouts and compile.

Need to find out if the problem is on the source environment for these reports or if they have been exported/imported to other environment and the problem lies there. If source is where the problem is need to verify NLS_LANG setting for user. Check db_resource, tabledef6.2, environment variable setting for the user, or default taken from Oracle.

Since the global compile did not give fatal error on ttadv335.layo for all reports then the NLS_LANG would not be a global problem.
If reports were exported/imported and the problem lies on the imported environment need to verify NLS_LANG for the user who imported the reports.