Credit Management Intermittent Hanging/Not Responding

Hi all,

I'm really hoping someone might be able to help with this one as it's becoming very frustrating.

We have a customer who has 3 users working within Credit Management on a daily basis. They have other users working within Sales, Cashbook, Purchase, Nominal etc and they have 25 users on their licence in total with probably around 15-20 logged in regularly.

They are running Opera 3 v2.91.00 but this issue has been going on for some time and spans older versions of Opera too. It occurs on Windows 10 and Window 11 PC's.

When they move between accounts in Credit Management on the 'Accounts' tab it intermittently hangs. Sometimes it will work correctly and sometimes it will hang for so long that the user crashes out and logs back in and then it works again for an indefinite period of time.

I don't believe there is a resource issue on the end users computer, they have 16gb RAM, SSD drives, 1gb network connection.

The same issue can occur in multiple companies within Opera, one company has quite a big sales ledger but the others are very small.

The time of day does not seem to make a difference, the issue can occur at all different times.

They use Sophos AV and exclusions have been implemented.

Does anyone have any ideas at what we should be looking at to resolve this?

Thanks in advance,

Alex

Find more posts tagged with

Pegasus - Partner General Discussions

Accepted answers

All comments

unknown

hi Alex, this sounds IDENTICAL to an issue we have on three seperate sites & we have never got to the bottom of this, so if you do find a resolution, Id be very interested in the outcome.

If you dial onto even the main server that has tons of resoucees & open credit Management, it is incredibly sluggish, taking an eternity to flip from one part of CM to another. I thought at first it was SQL based, & it was this that was the issue, but then I realsied I was completely mistaken & its just part of the VFP table structure

When you back the data up & restore it here, it runs absolutely fine. Its been a while since I looked at this issue, but I will have another look as Id been keen to get to the bottom of this, espeically when another partner is experiencing something similar - I thought it was just us!!

unknown

Please also check your release. If the release if more than 18 months old I recall some improvements done for multi-user Credit Manager which resolved some performance issues. Sachin will recall these

alex

Every time we've tried running CM on the Opera APP server it runs normally but the issue is so intermittent that perhaps it's just not showing the issue during our testing. Restoring the data here shows no problems at all. We suspect it may be a multi user issue and need to complete further testing for this.

Steve Loader

Evening Alex,

Just a bit of background information with regards to the Opera 3 Credit Management Centre:

The CMC honours the native database of Opera 3, hence in Opera 3 (VFP) the CMC uses underlying VFP database tables.

It uses the following tables:

Debtor letters are stored in sladlett

Options are stored in sladlopts

Diary actions are stored in slcmacts

When debtor letters are sent, an audit trail of the communication between Opera 3, and the Scheduler/SE Service is stored in zpubhist.

The primary table for the CMC is stran, so the larger the stran table the relatively slower CMC will perform.

Charles is correct in that there were some multi-user performance enhancements to CMC around 18-24 months ago, so the later the release of Opera 3, the less likely to encounter performance issues.

Finally, was the in-house testing performed in a multi-user environment? If not, then I would recommend doing so. As a general statement, CMC performance issues are almost always encountered in multi-user situations. In a single user situation, CMC is generally as fast as any other process in Opera 3.

I hope that helps.

Kind regards

Steve

Steve Loader

Hi Alex,

P.S. One other thing I forgot to mention relates to Diary Actions.

As with Costing Jobs, it seems that users of the CMC have an inherent dislike to completing Diary Actions, much to my displeasure!

I have seen customer data with thousands of outstanding Diary Actions, the majority of which are long completed, but have not been flagged as such in the CMC.

When the CMC form loads, and when you change between customer accounts, the slcmacts table is read to determine which Diary Actions are still active for the company as a whole on the Company Tab, and for the selected customer, on the Accounts tab.

The number of non-completed Diary Actions can have a very detrimental affect on the speed of the initial form load of the CMC (hence the initial progress bar), and changing between customer accounts. Worth a look.

I hope that helps.

Kind regards

Steve

alex

Hi all,

Thanks for the responses. We are still getting nowhere.

We've seen the hanging in action and got ProcMon logs during the point at which it hangs - we can't see the issue. The computer is doing nothing whilst it's hanging (CPU/RAM/Disk etc all showing nothing in the Task Manager). We did find that if you leave it long enough then Opera does come back to life from 'Not responding' but this took over 20 minutes in one instance.

The customer is running Opera 3 v2.91.

We've had Sophos uninstalled from one of the computers for a day - made no difference.

The data tables are very small - STRAN is 47mb. They don't use the CM Correspondence , I've checked for uncompleted diary actions but these were only the current active ones.

Our next steps is to get one of the users on the APP server and running it from there to see if this makes any difference. We are also in the process of setting up a server/client environment offsite for further testing.

If anyone else has any ideas then I'd be grateful!

Thanks,

Alex

VID021_Grid_Column Default Sorting.zip

alex

Morning all,

So I've been through the ProcMon logs again and found this:-

It looks like it's trying to write to C:WindowsCSC.......Googling what this is has led me to check if Offline Files is enabled but on this computer it is not.

Does anyone know why it would be trying to create this directory here? Running ProcMon on my computer does not produce the same results.

Offline files is not enabled on the server either, I've checked.

Thanks,

Alex

alan-bourke

In Process Monitor, with the log open if you select ToolsFile Summary, what file is been read fromwritten to the most ?

alex

I didn't know you could do that - very useful!

It's the C:WindowsCSC directory that's top of the list.

I've been doing some Googling and it seems that the csc service could still be running even though Offline files is disabled so I'll be checking this next on the PC.

I'm also wondering if I should change the Opera share caching to this

Thanks,

Alex

alan-bourke

Alex, it wouldn't hurt to change it.

Copyright © 2025 Infor. All rights reserved.