> The procedure is taking rows from a view, inserting them into a table and
then updating them. The table is used for reporting purposes and contains
about 60,000 rows in all, but only about 1000 rows are involved when the
procedure is run. The procedure runs fine for 3 months worth of data but
fails with error 458 (long trans) for longer time spans ie more rows.
>
Have you checked to ensure that you do not have a cartesian product
somewhere in the intermediate results? This could be generating a lot of log
activity without producing a large result set. I have seen this many times
with Peoplesoft queries.
>
> 3. Logfiles 99, Logsize 80MB
>
Don't know how big your db is, but this does not seem like a lot of
logspace.
>
> 7. Other procedures work quite happily with lots of rows. Especially the
week-end routine which inserts data into the table.
>
This makes me even more suspicious of a problem with the stored procedure.
>
> On the production server it seems that the oninit process is actually
killed when the procedure is run a second time and they have to reboot the
server. They obviously do want to try to reproduce this and so I cannot be
sure of this.
>
Sounds to me like you should report this to tech support.

Mark

sending to informix-list