Sometimes the software seems slow to update and refresh
Schedule View seems slow to updated/refresh
If the Schedule View is slow to update or load then see if these options help:
1, Be sure you are not loading every event you have ever made and asking the software to draw it on your screen. Do you really need to wait for every event you ever made to be put on screen? If you don't need to see every event instantly then enable the Schedule View option 'Only load events for the visible dates' in the menu Tools > Options > Schedule View.
With this option enabled only events for the dates you are viewing are loaded and not all events in the past and future. When you scroll or navigation to a new date then the events for your new date range are loaded. Scrolling to new date points are a little slower as the events in that range need to be loaded, but overall load time is substantially quicker as only a few hundred events may need to be loaded when needed rather than millions every time.
2, What auto refresh time have you set? (menu Tools > Options > Network) When using a file database (not SQL), each refresh will cause a full copy of your network database to the local PC locking out all other users during this copy process. This is not normally seen by a user. As your users increase, the amount of coping will increase, and as your database size increases, the copying will get slower. Be sure you don't have lots of users refreshing the file too frequently locking the database for longer period of time.
3, If you are using a file database then archive events for older years that are not needed.
4, Do you need to view 1000's of resources and their calendars with events on screen all the time at the same time. If not consider grouping your resources and only opening the ones you need to see, or use filters to quickly hide and show what you need.
Are you using the best database type?
Schedule It can store lots of data for you and if you are using it in a professional environment you should check you are using the best database type. If you find the loading or view refresh time is slow be sure you are using the best database for your situation.
* Are you using a file database or SQL database?
* If you are using a file, is your network fast and reliable and are all your users in the same office?
If you have chosen to use a file database on a network this is ideal for small database sizes and a small number of users (a maximum of 10 on the fastest network). The main reason is every time a refresh or update is made the entire database file is copied from your network to the local users PC. It is vital your network is fast and all users are in the same office, and not remote from the office where speed and stability cannot be guaranteed. Users with a slower connection will also lock out others whilst they are retrieving the data file.
To reduce the amount of data stored in the file database you can archive older events to reduce the file size. This will speed up network transfer times and reduce the network load. You should consider switching to SQL if speed is becoming an issue. With SQL archiving is not needed as only the necessary data is transferred.
As your database size or users grow it is advisable to use MSSQL or MySQL as your database as these are true network databases for larger scale storage and distribution between many local and remote users. Schedule it also works different with these database types and only loads/retrieves the data needed at that point so performance and reliability is substantially improved.
MSSQL and MySQL is support by Schedule it Professional and you can download Microsoft's SQL Express for free if you don't already have an SQL server.
File Database Users - Poor performance of Jet 4.0 databases under Windows 7/ Windows Server 2008 R2
Running a query in Access on a Windows 7 or Windows Server 2008 R2 computer may take longer than expected to return the query results.
Note, this issue does not occur if you run the query on a computer that is running Windows XP.
Microsoft have acknowledged the issue with Jet 4.0, but it appears that it may not be fixed as this product is currently deprecated. This issue will therefore continue to affect any new Windows 7 computers in the future.
The issue appears to be due to the Windows 'leaking memory'. This is caused by the system slowly making small incremental increases in system memory usage while a query is running - and this makes the query run slower.
Solution 1
A Jet 4.0 setting 'MaxBufferSize' can be increased to workaround this issue.
The default setting of zero allows the buffer to increase in value as required, but it can cause queries to perform very slowly while this is occurring. Also, it appears the first call to any database can determine the buffer setting to be used for the session and even subsequent connections to other databases. So it's possible that the setting can be set appropriately initially but then be insufficient for subsequent queries, impairing performance unexpectedly.
You may increase the 'MaxBufferSize' setting for Jet 4.0 by editing the Windows Registry.
The correct value to increase this setting to varies dependent on various factors, including the overall size of the database, the specific query etc. For a small database '50,000' should be sufficient, a large database may need '200,000' or more. It is recommended that the value entered is not greater than is required, as this may also affect performance; so it is better to try a smaller value and test and increase the value further if required.
The actual operating system being used will determine which of the following registry keys needs to be adjusted.
Windows 7 - 32Bit
Computer > HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > Jet > 4.0 > Engines > Jet 4.0 > MaxBufferSize
Windows 7 - 64Bit
Computer > HKEY_LOCAL_MACHINE > SOFTWARE > Wow6432Node > Microsoft > Jet > 4.0 > Engines > Jet 4.0 > MaxBufferSize
Solution 2
Use ACE rather then Jet...
https://www.microsoft.com/en-us/download/details.aspx?id=13255
Users with shared profiles or synchronised folders
Schedule it stores locally relevant data, and a cached copy of the database in the local users Documents > Schedule It 7 > temp folder. This folder must be unique for every user and not live synchronised or shared.
Issue 1
As local lock files are created by Windows these could be synchronised to other users PC's and lock out other users causing the software to stall until the lock file is released/deleted by Windows.
Issue 2
Local cache files could be inadvertently synchronised between users causing data loss from some users as their local changes are overwritten with the changes/local data of others.
Solution
Allow each user to have their own local or remote profile that is not shared with other users. Exclude the Schedule It folder from any offline or synchronised storage.
(slow, locked, archive, network, mssql, mysql, speed, performance)
Last updated, 12 March 2014, 10:35
Still need help? Contact Us
Join Us - Live Webinar
...
Close
Help Topics
Search
Contact Us