Client hangs on posting

bbrown

The client is running 3.60 (upgrade in the works) with a 45 GB database. The server is undersized but posting were working fine (slowly) until yesterday.

Now when a purchase invoice is posted, the client will hang (task manager list Navision as not responding). If the task is ended and then you go back into Navision, the invoice is posted.

The invoices are small. One or 2 lines, G/L accounts.

Any ideas/suggestions appreciated...

kriki

supposing you use a Navision-DB and not a SQL-DB:
-Are you sure you have the commit cache on your DB-server?
-Do you have enough DB-cache and enough memory to support the DB-cache (the DB-cache should always remain in memory and not be swapped to disk. This happens if you use more memory (all programs included) then the physical memory of the server)
-Do you have enough free space in the DB (DB used less then 80%)?

bbrown

Thanks for the quick reply.

This is a Navision-DB not SQL.

There is sufficient memory on the machine

Database space is a little low (~17% free) I am expanding as I write this, I will let you know the result.

I believe this is a server resource issue, but I am trying to eliminate any other possible issues.

kriki

bbrown wrote:

Database space is a little low (~17% free) I am expanding as I write this, I will let you know the result.

At least 20% free or 17% free wont change a lot. It gets bad very fast when the % free goes under 10%. But ideally would be at least 20% free.

bbrown

I expanded the database to 25% free and the issue remains. I also tested posting in single user mode (local client) and see the same issue. Considering the size of the database, I think this is a disk resource issue.

DenSter

You could try to optimize the tables, that could free up some space, although in C/SIDE I don't know if that will make a big difference.

<edit>
If you have the same issue on a standalone client it's likely to be a process issue, not a disk issue. Do you have any customizations to the posting process?
</edit>

bbrown

The tables were optimized about a month ago. The ledger tables are listed at 90 to 95% optimization is database information. This problem is only occurring in one company, but that company accounts for over 75% of the database.

bbrown

If you have the same issue on a standalone client it's likely to be a process issue, not a disk issue. Do you have any customizations to the posting process?

The postings are completing. It is just the client hangs and does not return control to the user. This started occurring yesterday. There have been no changes for several months. Also posting are running fine in the other companies (same database).

DenSter

The thing that worries me a little is that you say you can end the task from task manager and when you come back to Navision the invoice is posted.

Do you have any new customizations right around the time this started happening? Is the Navision box used for anything else? Can you reproduce it when you log in from the server machine itself?

kriki

DenSter wrote:

You could try to optimize the tables, that could free up some space, although in C/SIDE I don't know if that will make a big difference.

Actually on a Navision DB, this is not a good idea the increase write-performance in the tables. Optimizing is only good on tables where very few writes are done, because it optimizes for reading, not for writing.

kriki

When the session hangs, check the taskmanager to see if the fin.exe is taking (almost) 100% processor-time. This could indicate that an endless loop is going on.
Use also the debugger to see where you get before it hangs. This can help to find out why it hangs.
I have doubts that Navision just hangs in 1 company and in another not. This probably is a programming error and not a fin.exe bug.

DenSter

kriki wrote:

Actually on a Navision DB, this is not a good idea the increase write-performance in the tables. Optimizing is only good on tables where very few writes are done, because it optimizes for reading, not for writing.

I wouldn't say 'not a good idea', but maybe that you would not have as big of a performance increase in write operations as you'd have in read operations. During posting there are many MANY read operations though, and the optimization might increase the read performance just enough to make a difference.

DenSter

I do agree that this is probably an issue in the programming. It could also happen because of a large number of dimension values, or maybe automatic cost posting, or automatically updating analysis views.

bbrown

The issue has been resolved. The problem was caused by an analysis view that was set to "Update on Posting". The overloaded server and large number of G/L entries in the company compounded the problem. Turning off this setting returned things to normal.

Thanks to everyone for the assistance.

DenSter

Make sure you tell the person that uses the analysis view to update it manually.

bbrown

Already been done. Thanks for the reminder.

kriki

DenSter wrote:

Make sure you tell the person that uses the analysis view to update it manually.

And preferably when no-one is working like during the midday-pause.

DenSter

You could even set that up in a job scheduler. You could even create a small mod that puts a job scheduler in a NAS.

jungleboy

By the way, what kind of job scheduler that we can use? Any clue? U mean the one in service job module?

DenSter

That is the one I meant yes.