FREQUENTLY ASK QUESTIONS

The problem is very broad and can be divided into basic groups:
 

Server

When looking for a solution, start by finding out the MSSQL version and whether an Express version which has it's limitiations described on the SUPPORT page, is in use.

start Management Studio, log in to the required server and start: "SELECT @@VERSION"

YES we have EXPRESS

• The system probably uses more clients than SQL can handle.
• Check the sizes of Palstat databases, if the database "*data*" is larger than 2GB and the system is using roughly 10 clients or more, it is likely that the free version of SQL has reached its operational LIMIT.
• Consider purchasing a sharp version of MSSQL in the version recommended on the SUPPORT page.
• If the database "*data*" is smaller than 1GB, the system should work quickly and the problem may be in the general overload of the server as a whole. A frequent cause is an overload of the file system, where the hardware is used, for example, as a File Server and as SQL, or other services. Check the System Reserve Task Manager to see if there is an overload at certain times of the day.

NO we do not have EXPRESS

• Check the size of the database "*data*" and try to ensure the availability of RAM 1:1 with the size of the database on the server. 
• Ensure that the SQL server or the entire virtual machine does not have restrictions on RAM allocation.
• Check server reserves for RAM, CPU and DISK. If a slowing of Palstat at certain hours has been observed, it is likely that some maintenance is scheduled on the server at this time that will overload it. This typically occurs in the three-shift operation, where MSSQL backups are often scheduled at night.
• Above the database "*data*" you can run the script reindex table.
• Check that the server has not started writing excessively to the swap / paging file. (you have low RAM)
• Set up long-term monitoring on the server, which will show which server parameter reaches the limit values. An example of the settings is shown below, but the options for setting counters are great and it is possible to set monitoring only via a certain server, ie MSSQL server.
• 

Client

The issue of the client station is broader in that Palstat requires a stable connection to the SQL server. For example, WIFI cannot be recommended, where a small network outage or lagging may occur during disruption, and the application will crash frequently because the connection to the SQL server will be lost. The same application behavior occurs with a faulty network element. We know from experience that for some customers, replacing the network adapter at the client helped to improve the opperation of the application.

Starting the application can be sped up by placing the entire PALSTAT directory to clients. This significantly speeds up the loading of the application, but at the same time makes it very difficult to perform PALSTAT updates. If the application on the server is not a problem to find out through "Open Files" which user is currently using the application, quit the user and work on the system upgrade. In the case of placement with clients, this is not possible and it is necessary to rely on the fact that no one really uses. It is also necessary to ensure the distribution of the applications to clients when performing upgrades. Therefore, the placement of applications on clients is not recommended and is only suitable for selected clients, eg when using the application via VPN.

In some cases, when users load an application from the database  a huge amount of data to be rendered into the list, it is appropriate to consider the deployment of the global filter  (see manual) when the loading will be accelerated. Example: a user opens the Complaints module, these contain 300 thousand records (80MB), but 90% of users are not interested because they are older. Set the filter for the last 2 years, for example. Loading will be limited to 5,000 records and opening will be much faster.

Example of filter settings for the complaint module from 2005