On January 1 each year our organization does some accounting via ARev that requires 4 new tables to be created (e.g. On Jan 1,2011 tableOne_2010, tableTwo_2010, etc were all created). In the distant past, we ran into the issue of the image being too big as a result of this. The problem has popped up again and now when starting our application we get the error:

The row OURAPP_IMAGE exceeds the maximum length. The current process will terminate without saving.

…upon launching our application followed by warnings that tables that are usually attached could not be and a crippled application. How do I resolve this problem?

Thank you.

Can you restore the data/system back to the point before running the Jan 1 process? Then rewrite the process that creates the OURAPP_IMAGE record to split it up into chunks if it gets say over 50K.

If not download the OI demo version and attach the file in OI and delete the offending row from the file. Make sure the network driver is All network 2.1 before you do this.

You may have to do some fiddling to attach the files in OI if the demo version won't allow you to create an application with the same application/account name as in ARev.

If you migrate to ARev32 under OI you will no longer have the 64K record limit.

Of course if you are already running 32 bit OI there would be no need for the demo version.

Warren,

Our data is volatile and time sensitive (i.e. the conversion program is required to be run on 1/1) so rolling back isn't a possibility. I am unsure of the significance of the OURAPP_IMAGE record but I'm guessing it has to do with keeping record of the attached/existing tables, as the 1/1 program does not interact with this record directly. The message citing OURAPP_IMAGE does not give a location where I would find this record. Where can it be found? Would it be possible to break this record up now?

We have licenses for OI but I fear that deleting the row in OI (as the offending row is too large, likely signifying useful data) will cause undesirable results. We do have a method produced to move and re-index all of our ARev data to our currently in-development build of ARev32. Is there a way to have the two systems share the same data set?

Sounds like a quickattach image. Really you just need to eliminate the quick attach and perform manual attaches in the VOC, it'll be slower but it'll eliminate the quick attach error message.

See this message

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

After reviewing the linked messages I now recall that all one needs to do is delete the xxxx_IMAGE record from the SYSTEM table and delete or comment out any of the SETATTACH commands in the code. QUICKATTACH is no longer much of a time saver with the quantum leaps in disk, cpu, bus and network speeds since the early 90s.

In the 30 years I've been working with multi-value systems the most wise thing to have is to disaster recovery backup of any database prior to running any time sensitive processing such as first of the year processes. I'd hazard to guess that all users are required to log out until the year-end process is completed and since the application is essentially dead in the water new data entry has been minimal to say least. If data entry goes on during the first of the year process then the process has some way of taking a snapshot of the data or filtering out the post first of the year data. So any post first of the year process data could be extracted and merged into a disaster recovery copy.

I think the first of the year disaster recovery plans need to be seriously reviewed.

View this thread on the Works forum...