Long read, I know; however, this problem has long been in the process of solving to no avail. This is a report of our office’s issue with TimeSlips 2012 that I typed up to a (2nd) Rep to try to analyze an issue we are having with our TimeSlips performance. I am revisiting this issue after two country-wide-well-known (in regards to TimeSlips troubleshooting) reps have had their go at our system, unsuccessfully, so here's the report of the issue/prior-troubleshooting:
I would like to start by mentioning that we have one, maybe two users, that are always in TimeSlips, needing to use it constantly (many others are in and out through the day), so “exclusive time” with the database is generally limited to short periods, or best, lunch hour.
We have TimeSlips installed on our office owned server, in a county datacenter, and we operate on the county’s network. One thing to keep in mind, is that our 2009 installation ran much faster; albeit, still slow, but usable without much frustration on the same server, over the same network, right up to the installation of 2012. It has been a two years since we had heavily tested TimeSlips, so I will list-off things that, from what I recall, we had tried.
1. The standard, run-o- the mill recommendations from both T1 & T2 support, including everything on their .pdf list.
2. Moved it to different servers (other than our own) at the county, some being SANS, and this produced a fast result; however, when other users were moved into the DB, the problem resurged.
3. The network settings and NIC card settings on our server were tested (trial & error) via one of our IT Sys Admins.
4. Moved the DB local and it operated fast; ran as peer-to-peer, and I can’t remember, but I believe it was slow.
5. The network speed had been tested and transfer speeds seem adequate.
6. The Virus protection has been tested as off on both server and user end.
7. I had removed our entire installation, reinstalled TimeSlips using a clean, full installation copy of 2012.
We do not exceed the number of Slips or Matters (called Logs, in our office), and we have all features turned off, running in Basic UI mode. Some of the functions noted as exceptionally slow are Saving Slips, running reports, and something that was very noticeable in speed declination was the scrolling up in our Matter (Log) list and, in the same list window, per-character indexed search seem to look almost as if it were page filing (refreshing the window from top-down) when you type each character heh.
This is my report (see below) I found from late 2011 regarding some of the things another rep and I had tried in order to remedy the TimeSlips problem. Take note the second paragraph; I found after having added other users, the database when on another server, slowed down. One naturally would think that this is due to too many users… the point I reached, at which my mind was absolutely boggled, was that if all users leave the database, and I clear the license list (or if I created a copy of the database folder), that certain users, many times, being the first user back in, will operate at fast speeds, until another user enters the database; after, it will not matter how many users are in the database (even just one), it will run slow. So this is my report regarding the first rep's work:
“Please see (name removed, Rep)’s report on his findings. Based upon his findings, one of our Sys Admins checked the settings of both the Server-end and Workstation-end network adapters. Possible problematic settings, on both, have been rectified. After having done so, the database continued to run slow. Having read (the Rep)’s report, we then attempted to copy the database to the I: drive on the network (another drive on another server), which rendered results like before: a fast operating database. It was then suggested to copy to a server more comparable to the OCADOX server (our server) because the setup of the I: drive is quite different and more robust (being a SANS setup). We then proceeded by copying the database to one of our mail servers. After overcoming some obstacles with doing so, we successfully connected one of the local workstations to the new database and it ran quickly.
At that point, it had seemed that anywhere the database was located, except for our own server, the database would run fast. Which verifies (the Rep)’s findings; however, once we reached this point, we decided to add other users into the newly copied database. The reason why this had not been done before is that you have to move everyone to one database, as you can’t have people making entries on two separate databases, as there is no option to merge.”
This is about the most I can think of. I would be happy to clarify any of these points. I do want to also mention that I tried multiple times to revert the DB by exporting all information, and rebuilding it in 2009, and eventually came close (off by around 2:05 in time), but ran into many issues that did not seem logical, like straightforward import processes that turned up improper results, rather agitating as you can imagine.
That was the finishing of the report I had typed for the 2nd (last) rep. To be clear, migrating back to 2009 is not an option anymore. I am not looking towards upgrading the software when we have no promises of it functioning. We are, however, coming upon a time where I will be reinstalling all our software (including TimeSlips 2012) from scratch onto a brand-new xeon dual-octacore server running off an OS/Applications SSD. All I am looking for are methods of finding a solution to our problem. As stated, it’s been awhile and I am very rusty in regards to TimeSlips (I’m not a daily user), and am just trying to make my best attempt to avoid this issue on the new server, if possible. One other thing, the last rep tested many changes in our BDE Settings if I remember correct, and it’s VERY hard to remember, but we may have seen some very minuscule results? Mind you, this is simply a 12 user (max) setup, and an average of only 2-3 users are in the database. Also, the current Server (and new server for other reasons) is running Server 2008 R2, and workstations are currently mixed platform of XP/Win7 x86. Lastly, we've had one rep, not previously mentioned, who's been with us through the entire process and to this day still helps us with all our needs; however, together we've sadly been stumped regarding this issue. Whether the Subject of this post seems cocky or not, I actually DO want to solve this problem, and whoever is capable of helping me solve this problem will be considered a lifesaver :)