Drill down from Chart of Accounts lock up client

idiot

4.02 SQL2005

Anyone has encountered the problem of drill down to Net Change or Balance of Chart of Accounts freezes the whole client system? There's no network activity, harddisk activity, CPU activity. The number of transactions in this Account is less than 50. Even if the entries are shown, if you want to scroll left & right or click on any field, the system freezes again.

However, if filter direct from the General Ledger Entries, the response is almost instant.

Any thing to look out for?

David_Singleton

How many Gl Entrys are there?

I would suggest you upgrade to better executables.

idiot

There's less than 50 entries here. Upgrading is the last resort. Is this a known issue with 4.02?
No meddling of codes found.
It took more than 10 mins for the G/L Entries to be displayed, after which when attempting to scroll or click on other fields, it locks up again, wait for another 10 mins ...

Turning on debug mode, the debugger freezes as well onAfterGetRecord...

David_Singleton

So you have a company that has only ONE GL Account? Is this some play company? Can you check.

Go to file Database information, find table 17 and see how many records there are.

suvidha

If u r using SQL database, see if the relating SIFT key in G_L Entry has a maintainSIFTIndex set to TRUE.

idiot

David Singleton wrote:

So you have a company that has only ONE GL Account? Is this some play company? Can you check.

Go to file Database information, find table 17 and see how many records there are.

There are about 2.5 million records in total, for the specific account there are less than 50 records.

If the system locks up due to the user trying to access records not displayed on screen by scrolling up and down it is understandable.
However all records are being displayed on screen. There's no additional calls to fetch more records. Why does the system lock up, even for the debugger as well? ](*,)

idiot

suvidha wrote:

If u r using SQL database, see if the relating SIFT key in G_L Entry has a maintainSIFTIndex set to TRUE.

I compared the keys in the live system with Cronus, everything is the same.

David_Singleton

idiot wrote:

David Singleton wrote:

So you have a company that has only ONE GL Account? Is this some play company? Can you check.

Go to file Database information, find table 17 and see how many records there are.

There are about 2.5 million records in total, for the specific account there are less than 50 records.

If the system locks up due to the user trying to access records not displayed on screen by scrolling up and down it is understandable.
However all records are being displayed on screen. There's no additional calls to fetch more records. Why does the system lock up, even for the debugger as well? ](*,)

Its not relevant how many records are in your filter set. Its relevant how many records are in the table. I suggest you upgrade the executables to nav sp3 build 26565 at the latest.

Do you have your TempDB on a dedicated drive?

idiot

David Singleton wrote:

Its not relevant how many records are in your filter set. Its relevant how many records are in the table. I suggest you upgrade the executables to nav sp3 build 26565 at the latest.

Do you have your TempDB on a dedicated drive?

As the client put it, can upgrading to sp3 guarantee an improvement to justify the cost of doing an upgrade?
What if it's still the same after an upgrade? The posting of documents are at reasonable speed which makes justification difficult...

Maybe adding more ram helps....

David_Singleton

idiot wrote:

As the client put it, can upgrading to sp3 guarantee an improvement to justify the cost of doing an upgrade?
What if it's still the same after an upgrade? The posting of documents are at reasonable speed which makes justification difficult...

Maybe adding more ram helps....

This is where the partner comes in. Time for some testing.