• Welcome to the upgraded JDELIST forum and thank you for your patience.
    Please restrict discussions and issues regarding the new forum software to the Off Topic forum. We will be monitoring that forum for issues.
    If you have trouble logging in, please reset your password using the forgotten password form: https://www.jdelist.com/community/index.php?lost-password/
    If you are unable to successfully reset your password, please contact us: Click here!
    We hope that you enjoy the upgraded forum.
  • Introducing Dark Mode! Switch by clicking on the lightbulb icon next to Search or by clicking on Default style at the bottom left of the page!

Slow UBE - some are very slow....

We have a couple UBEs, that run for HOURS.

R09705 will run, sometimes, for more than four hours... we have a fairly beefy 400 - so the OPS guys want the 'developers' to figure out why the UBE takes so long to process.

The UBE is not modified - but there are Select statements on the Version
I have looked at indexes.
I have looked for inherent issues... can't see any.

Are some UBE(s) supposed to run for many hours?....

The R09705 compare F0911 to F0902 to check for out of balance period. If
there are two many records in F0911 and F0902 then it will take long time. I
would suggest to pass in data selection i.e. compare the last months data.
There is no use to compare data you have compared before. Use the Actual
Amount "AA" ledger type to compare or other some other ledger which meet
your business criteria. There is no need to compare ledgers which would be
out of balance by design. This should cut down time. If this does not
work, please let me know at moin@sumcomputers.com. We have done numerous
things to increase performance and non of our process run for hours.
It shouldn't be a problem with the R09705, but have you considered that some of your slow UBEs might be wasting time waiting for record locks to be released by other processes?

Do the batches run at the same speed when no one is in the system and nothing else is running?

I've been watching them - and I don't see any record locking issues.

These jobs run at night.. and they take, about, the same amount of time each run.

Hmm. I have no experience with the R09705 - what are some of the others that are running slowly?

Making sure that indexes exist for the select/fetch statements is another obvious one, but that shouldn't be much of a problem with base objects.

Some do run for hours.

When one is in question I usually start with a log to see if there are any unusual delays in SQL or business function calls.
I hadn't thought to review the debug log for delays... that is a good catch, I'll look into it some more.

Has someone released a tool to 'better' read the debug log? I'd heard that there was one - but I hadn't seen a release.


I use an Access DB to look for delays. It is attached.

Open Form1, enter the path and name of the log, hit the parse button.

You can then look at the tables that are loaded and sort them by the response or delay time to find the long ones.

It is nothing fancy.
Try the "Performance Workbench" from the KG (Support > performance workbench).

It will take a log and produce a "call stack" telling you how long each BSFN call lasted

Best Regards,

I modified the data selection to eliminate most of the records. This cut
our time down quite a bit.

Select Fiscal Year = 2003; GL type = AA, company,

I tried selecting YTD value <> 0 and that worked, however, you may miss some
integrity issues where you have transactions in F0911 but 0 in the F0902


Tom Crawford