 |
 |
|
|
If you are experiencing users crash in specific areas of the program on an ongoing basis or users are reporting the system running slowly, please refer to the information below:
This will be apparent when the crash is re-producible when doing a specific task and is present on both the server and the workstation, if this is the case a repair of the software will need to be run.
Details of how to run a repair can be found here. If possible it is suggested that you upgrade to the latest version, details on how to upgrade are found here.
In extreme instances if a repair doesn’t resolve the issue a re-install needs to be completed.
This will be apparent when one machine crashes, all the machines on the network crash, you should see an event on the server stating the SQL ‘can’t accept any new connections’.
If this is the case we need to know the ‘Total physical memory’ and ‘Available Physical memory’ these can be found by going to Start |Run | msinfo32.exe. If the available memory is low this could be a cause of the IRIS crash.
If you have on average 10 or more users you should be using SQL Standard which has a uncapped memory usage whereas the express edition (provided by IRIS) has a 1GB limit + around a 500MB cache.
To see how much RAM SQL is using at any given time you can open Task Manager | Processes | sqlservr.exe this will tell you the current usage figure.
In some cases, the sqlservr.exe
process can accumulate memory if it has been running for a number of days.
Restarting this service can greatly reduce memory usage which in turn
improves performance.
A guide on how to restart the SQL service can be found here.
You must exit IRIS before restarting the SQL service to avoid any corruption or data loss. If this does improve performance it may be worthwhile to create a batch file or scheduled task to restart the SQL service daily. There can also be an issue when Microsoft Exchange is running on the same machine as the SQL, as both programs (only SQL Standard) both use as much memory as they want they SQL’s performance can be effected, again this could be contributing to the low level of available RAM which can cause slow speeds/crashes3
Party apps that run scheduled tasks can spike memory usage and CPU usage which can cause IRIS to lag or even crash, the most common applications are back-up utilities
Occasionally we tend to find the IRIS SQL database log file (LDF) can grow extremely large 10GB+, this can be shrank right down to a mere 0-100KB, a guide on how to do this can be found here.
If we can ascertain that the issue is isolated to a single or a few workstations but the majority are working fine then we need to firstly compare these problem machines to the working ones i.e. specifications, operating system and what anti-virus is on that machine also how the machine connects to the network/IRIS, whether it’s via a wired/wireless connection (IRIS should not be run over a wireless connection), if the IRIS is ran over a UNC path or over a mapped drive.
If issues have recently developed on the problem machine(s) then we need to see if there has been any new software installed, any failed windows updates, any root operating system issues (SFC /SCANNOW etc..)
One of the most common issues surrounding specific workstation crashes is the anti-virus blocking IRIS or slowing it down to the point to where it crashes, so we need to ensure that any anti-virus or live scanning software has the IRIS directory excluded either from the mapped drive or the UNC path.
There is an alternative method to connect the workstations to IRIS it’s called ‘cliconfg.exe’ it creates a ‘SQL Server Alias’ forces IRIS to access SQL a specific way, instructions to do this can be found here if you’re using a named instance i.e. IRISPRACTICE or SQLEXPRESS you will need to know the dynamic TCP port. Instructions for determining which TCP port you are using can be found here.
If speed is the key issue then to diagnose I would measure the time taken for a task to be completed on the server and would expect the workstations in an ideal environment to be within a 50% threshold of this, the previous items listed will contribute to the speed of IRIS.
We also see machines that lose connection to the network which will cause IRIS crashes, ensuring the server name and IP address can be pinged from the workstations is essential, extended pings can be run to check whether the connection is dropping out and then can be diagnosed accordingly.
If you use terminal services and have IRIS installed as a workstation on the TS and are running Server 2008R2 there are some issues, a double entry in the event logs with the title ‘Windows cannot access the file for one of the following reasons…’. I would get in touch with us if you experience this issue but the resolution for this is to install the IRIS locally on the TS (SQL can remain where it is). Further details can be found in KBIAS-10380.
If you have just updated IRIS, please check your network adapter’s link speed. We have seen Gigabit network adapters auto negotiate to a link speed of 10 or 100mbps rather than 1gbps.
To check this go to Control Panel | Device Manager | Expand Network Adapters | Right-click the necessary adapter and choose properties then go to the Link Speed tab. This will tell you the speed and give you the option to change it.
Changing this setting can drop the connection for your network. Consult your IT Support before making any changes.