|
From: | James Busser |
Subject: | Re: [Gnumed-devel] Re: Development testing on Production (?) servers -- was 0.3-rc4 released |
Date: | Mon, 18 Aug 2008 21:02:52 -0700 |
It just occurs to me that at the point of upgrading to version (current +1) of the database, there is a danger in all of the old clients remaining pointed to the (now deprecated) database because there is nothing to stop or even warn anybody who would be using the "old" client against entering new data into the now-deprecated database. Even if the praxis IT-support person is able to get access to all of the on-site computers (and all of the user accounts within them, in case there are copies of the client within users' individual /home/ directories) there can be copies temporarily inaccessible to the IT support person, such as on the laptops or home computers of some of the clinicians. Would it be safer if the final step of the bootstrap, assuming that it had encountered no problems, to rename the database that had been updated for example rename v8 v8arch This would protect the old clients from being able to access the old database in the mistaken belief that they are still accessing the "live" database. Would a good solution be to build into the config file a login selection named GNUmed archive that would only work with a deprecated version name. For example the client that by default expects the current (devel or production) version to be v9 would include a config for version v8arch ?? On 18-Aug-08, at 6:21 PM, James Busser wrote:
|
[Prev in Thread] | Current Thread | [Next in Thread] |