Erp Forum: The Sage Forum Site

Hi all!

Right, we have an interesting bug in our Sage Line 500 system. Sometimes, when a user closes an option (ie Fast Order Entry, Transactions, Stock) etc, the corresponding application on the server fails to close.

This leaves redundant applications running on the server, sometimes using exactly 25% of the CPU resources.

At the moment, I manually kill these applications by going in to the User Activity Enquiry, checking the dates for each application, finding the applications running from previous days, noting the PID for each one, and manually killing them on the server.

As you can imagine, this is a bit of a boon first thing in the morning.

So, my question is: Is there a fix to this problem, or is there a way to create a report to automatically generate a list of PIDs for old applications, with which I could create an automated system to kill them?

Thanks in advance for any help!

Yours

Sage Line n00b!

Hi,

We have a similar problem.
I am sure it is possible with SQL.

Find all your open processes that are before a certain date and write them to a table.
Use the Kill statement to kill the processes in said table.

If you are not ok with SQL - I would not recommend 'trial and error' as you may kill some required processes.

A quick search of the web for 'kill sql server processes' and I found a script that does all of what you want.
Finds open processes, writes a table, uses that table to kill processes.
With very little refinement/editting it would do what you want.

Be very wary of running the script as you may kill required processes

Gordon

You are not alone mikeyd,
We have similiar problems?
They seem to be confinded to a few users, and I can't put my finger on exactly what their problem is.
Yes, the manual process you described is painful.
I'm not sure I trust my basic SQL knowledge to follow or-8's suggestion.
I'm sure I'll dig myself a hole!!

Regards,
michael_aussie

In our experience.....
One of the main reasons for having open processes left in the User Activity screen is the basic fact that users don't close sage correctly.

They just click the top right hand corner to exit the screen.

The procedure should be to use File Disconnect then close the screen.
The failure to disconnect leaves these spurious processess that become a bug bear.

Also note that there is a limit set on many servers for open processes.
If they are not tidied up there could come a point where the system will not let users login as there are no 'free' access points in which to open the new process they are requesting. (I think ours is around 200 so we have never got there yet.....)

And low and behold - I have just checked and we have user activity dating back to August logins which have obviously since been closed.

Alas, we have 'managed services' and I can no longer kill processes on the server.

Gordon
OR-8

hi Or-8

Are you getting everyone out of sage before you run the kill "sql server processes" script?
Or have you managed to change the script so you can add the pid of the process you want to kill?

Thanks

I would never run the script unless I knew I was only killing 'dead' processess which I know have been left due to users incorrectly logging off.

My SQL is not so good that I could do that. (self taught and still learning better things weekly...)

If a new table was created that contained the pid's (that need to be killed only!) and there was a join to this table it would , in effect, only kill those processes.
We don't have enough 'dead' process in the system to further develop the SQL script.

As I stated - we now have 'managed services' - for political reasons I am no longer allowed to access the server directly.

I can, however, check tables within SQL to see who is accessing the system as I still have enterprise manager client on my P.C.
That way I can contact the 'old' process owners and ensure that they are 'dead' connections before killing them. (Which I do individually - currently)

Gordon
OR-8

We are still having problems with "dead" processes.
I have written script that identifies the sessions dead sessions, but I cannot find where (which table/field) to find the session PID???
Without this number my list is useless.
Any suggestions???

A GOOD STARTING POINT:
from csmaster

SELECT start_time, last_change_time, terminal, username, application_option, ua_checksum, working_directory, module_name
FROM scheme.uar
ORDER BY username, start_time

Depending on version and or connection method etc.....you should be able to set a default time-out (ie: clean-up) to remove old sockets on Sage 1000 / Sage L500 V5 and above. Their was also a patch fix provided by Sage on this issue and most resellers should know them as a matter of course.

Kind regards
Tony Bradburn
Gold Disk Computers Limited
Website : http://www.golddiskcomputers.co.uk

AnthonyBradburn wrote:Depending on version and or connection method etc.....you should be able to set a default time-out (ie: clean-up) to remove old sockets on Sage 1000 / Sage L500 V5 and above. Their was also a patch fix provided by Sage on this issue and most resellers should know them as a matter of course.

Kind regards
Tony Bradburn
Gold Disk Computers Limited
Website : http://www.golddiskcomputers.co.uk

Hi Tony,
We are using Sage1000 version2.2.
Our reseller doesn't seem to be aware of a patch??