Hi Noam,

Thanks to your suggestion the problem has been traced and solved!
Because the problem was caused by a very sneaky setting inside Action Zen V15 I'd like to explain exactly what caused this issue.

As of V15 there is a new setting in Action Zen in the Performance Tuning settings: File Close Delay
This option is standard set to 50 miliseconds.

The option was apparently added because applications like Magic, and therefore also the FireFly migrated code, appeared to be using rapid open, close and re-open of DB tables. This caused performance issues because of data flushing from cache and whatever needed to be done before re-opening the tables. To avoid this, the new setting kept the table 'opened' a little bit longer in case it needed to be re-opened again.
Since we in our code check the table for content (DBrecs > 0) and if so do a DBDEL() right after that, the table was still opened and thus the IO.Delete could not be performed.

Setting this new option to '0' turns this new feature off and the databasemanager behaves again like earlier versions and that solves this problem.

I hope this can be of help to anyone who experiences problems like these.

Thanks for the very rapid response!

On Mar 25, 2023, at 5:12 AM, Keith Canniff <kcanniff@...> wrote:



To all of you using Actian Zen 15

 

I pulled this from the FireFly Migration group since it’s appropriate for Magic .

I’ve removed the Firefly specific references

 

Keith Canniff

 

 

On Tue, Mar 21, 2023 at 6:06 PM Desert .44 <retammes@...> wrote:

Hi Noam,

Thanks to your suggestion the problem has been traced and solved!
Because the problem was caused by a very sneaky setting inside Action Zen V15 I'd like to explain exactly what caused this issue.

As of V15 there is a new setting in Action Zen in the Performance Tuning settings: File Close Delay
This option is standard set to 50 miliseconds.

The option was apparently added because applications like Magic, and therefore also the FireFly migrated code, appeared to be using rapid open, close and re-open of DB tables. This caused performance issues because of data flushing from cache and whatever needed to be done before re-opening the tables. To avoid this, the new setting kept the table 'opened' a little bit longer in case it needed to be re-opened again.
Since we in our code check the table for content (DBrecs > 0) and if so do a DBDEL() right after that, the table was still opened and thus the IO.Delete could not be performed.

Setting this new option to '0' turns this new feature off and the databasemanager behaves again like earlier versions and that solves this problem.

I hope this can be of help to anyone who experiences problems like these.

Thanks for the very rapid response!