- December 5, 2011 at 10:25 am #31282
ClinicOffice has an AUTO-UPDATE feature which uses your internet connection to check for updates. When it finds an update it will let you know, and you simply need to follow the on-screen prompts to install the update. If you decline the update, then the program will simply ask you again later on.
By default, the auto-update checks for an update once per week (scroll down for information on how to change this), but you might still want to manually check for updates – here’s how :-
METHOD ONE (recommended)
Click the TOOLS tab (at the top of the main screen) then click “Check for Program Updates”. ClinicOffice will perform an immediate check to see if there is a more up-to-date version available and it will offer to download and install it for you.
You can see what version/build you are currently using by clicking the HELP tab and then the “About ClinicOffice” button. You can then compare this against our latest release by checking the Program Updates page on our website, which also has a link to download the latest update :-
Q. Can I change how often ClinicOffice automatically checks for updates?
Yes, you can adjust this setting by going to the VIEW tab, then click “ClinicOffice Program Settings” and you will see the “Auto Update Settings” options on the “Local Computer Settings” tab. From there you can turn off auto-update checking altogether or you can change the frequency of the checks.
Q. How do I find out what’s changed in an update?
On the Program Updates page on our website, there’s a link to our “change log” which tells you what’s new in each update. Here’s the direct link :-
Q. Why do I get a warning about updating ALL my computers?
If you have multiple computers running ClinicOffice and sharing the same database, it is best to update them all at the same time. This is because an update may need to change the structure of your database. If you only update one computer (which in turn updates your database structure), then your older versions of the program won’t be able to work with your database as the structure is not expected.
The simplest solution is just to set aside a few minutes to update all your computers at the same time e.g. at the end (or start!) of the day.December 6, 2011 at 11:43 pm #32950
Listed below are a couple of queries I have regarding applying updates.
1. Changes I’ve made to CO (using the appropriate interfaces)
Through the interface provided, I’ve changed screen layout, added custom fields and created views for reports*.
If I apply the updates, will all this stop working?
* Note: The reporting engine invariably crashes when the SQL Source query has nested queries and search criteria is entered. To get around this, I’ve created views (using the Advanced DB Operation interface) so the SQL Source is simply “SELECT * FROM view_x_report_name”.
2. Testing on a non-production version
I’d really like to test it out on a non-production version of the database. I’m guessing that to do this, I’m going to have to:
. install the current version of CO on a separate PC
. backup my db and copy the backup file to the separate PC
. transfer my Professional Edition licence to that PC and restore the backup to create a non-prod CO env
. apply the update to the non-prod CO env and regression test to ensure all still works ok
. if all ok, transfer my licence back to the PC with the prod environment and then apply the update
To save the messing about with transfer of licences, are you able to provide a limited life licence?
AdminBoyDecember 7, 2011 at 11:38 am #32951
To answer your questions in turn:
If I apply the updates, will all this stop working?
Updates do not change screen layouts, custom fields or views you have created for reports, nor do they change your data in any way – they may update the database structure (usually by adding new fields) but changing the “structure” does not mean changing the “data” – if that makes sense! Our changelog lists the new features/improvements/bug fixes in each update.
I’d really like to test it out on a non-production version of the database
In order to do this, you would simply backup your current database and then restore the backup, but as a “new database” and name it something like “testdb”. You can then switch between the databases on your logon screen.December 8, 2011 at 5:59 am #32952
Does the update change the database or the software installed on PC?
I’m thinking that if it’s the software on the PC, creating a ‘testdb’ database and then applying the update will not ‘protect’ the production database. Applying it on a completely seperate PC would be preferable.
Could you advise?
Thanks.December 8, 2011 at 11:22 am #32953
>> Does the update change the database or the software installed on PC?
Updates change the software installed and will sometimes change the STRUCTURE of the database – usually this involves adding new fields for new/improved features. It will not break or change any data you have entered including custom fields, screen layouts or custom report SQL.
By way of a “technical” reply to your earlier comment :-
>> The reporting engine invariably crashes when the SQL Source query has nested
>> queries and search criteria is entered
This is because the report engine we created for ClinicOffice has the ability to build search criteria and create a dynamic search form by parsing SQL statements. A simple nested SELECT statement in the WHERE clause should be ok, but complex nested SELECTs will confuse the parser and should be avoided. As you rightly deduced, using VIEWS is a much better solution.
You can probably appreciate that very few customers use SQL to generate their own reports – this is something that our Support Team would usually do. However once you become familiar with using the ClinicOffice reporting engine, you’ll hopefully find it’s a very powerful tool!
>> To save the messing about with transfer of licences, are you able to provide a limited life licence?
>> Applying it on a completely seperate PC would be preferable.
There really is no need to be concerned about updates affecting your reports or your custom changes. If our updates affected custom screen layouts, custom fields or reports then we would receive THOUSANDS of support calls from unhappy customers after every update!
As Daniel mentioned previously, the best way to proceed would be to have TWO separate databases (one for TESTING, the other for PRODUCTION) on the same computer and simply keep your software up-to-date.
If you wish, you could install the TRIAL Edition on a separate PC which will work for 30 days and will allow you to work on another computer. If you decide that you want to work on 2 PCs on a more permanent basis then you could purchase an additional Professional License for the second computer.
Hope this helps!December 9, 2011 at 6:32 am #32954
Thanks for your comprehensive answer.
Having worked with IT software vendors like Oracle and Microsoft for 20 years, if I had £1 for every time I was advised that the update will not impact the system so you can apply direct to the production environment… 😉
Joking aside, I’ll follow your advice, thus:
* create the test database
* update software on 1 PC and test
* upon success, update production database and other PCs
You must be logged in to reply to this topic.