Using 4.0 I just did a merge/rebase of today's current head. When I re-ran setup and pointed it to my existing database, my codes table was empty. Perhaps this has to do with the new inclusion of icd9 codes as part of setup. It's a minor nuisance for me since I can reload my codes table in development easily enough, but I think this could be bad for people who are upgrading.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Setup, by it's nature is supposed to start clean. If you want to keep your current data after refreshing the code run the sql_upgrade.php. The easy way to know if this needs to be done is to use the urlhttp://yoursite/openemr/admin.php - it will warn you that an data upgrade is needed and let you launch it from there.
-Tony
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have always had an issue where every time I Install the newest Dev. head (and I do that about weekly on my test machine), I lose almost all settings and data.
I resorted to exporting individual database tables e.g lists, layouts, codes, users etc. then importing them into new installation this can be tedious. I usually have to import table by table, sometimes having to first empty default installation information from tables before import can succeed.
Could you kindly expound on the steps to be taken regarding the sql upgrade.
Regards,
Mukoya
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Setup, by it's nature is supposed to start clean. "
This is not consistent with the option in setup to specify an "existing" database, especially since I wasn't upgrading, but simply pointing a 4.0 web server to an already running 4.0 database.
Consider the scenario where you want to have 2 webservers pointing at a single database instance for load balancing reasons.
You setup webserver 1 and create the database at that time. You do stuff, and then at a later time you want to build a second webserver and point it to the already existing database. If you choose "existing database" when setting up the second server, by your suggestion it's supposed to be a clean start, you'd lose things you had done on the first server.
The second server is not an "upgrade" it is a new setup, but shouldn't do anything to the data in that case.
I was expecting by running setup for the new server to simply be for specifying what database login and passwords to use, not to change data.
Furthermore. SQL_upgrade does not seem like the correct way to keep my current data as I am already on 4.0. I understand that I might not pick up needed schema changes, by using an existing 4.0 database. However, I still don't think it makes sense that setup should delete existing data.
@mukoya
I know now that I should just in the future hand edit my sqlconf.php file to accomplish what I was expecting, and you should be able to get what you want this way too. We won't get schema changes by doing it that way, but we won't have to reload our data either.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually went through same issue first time, selecting the "I already have database Installed" option rather than "have setup install database". I then provided the password and all. setup completed successfully and I was shocked to find all data wiped out. At that time, I din't know about the limitation and thus had not backed up anything. It appears OEMR setup uses the credentials to log in to mysql and proceeds to overwrite all data. Only thing is it saves you another PHP/Mysql installation by using pre-existing database.
I think this is an important Issue that future development could address. For example, we could have setup warn us or give option to either retain or overwrite data as loss of data can be very expensive.
This link gives a different approach. not sure if it will help. I have not yet tried it out but as pointed out, it is a 3.2>4.0 upgrade.
Yehster,
The issue here is that the option your using is specific for users whom need to set up an empty shell database (ie. do not have root access) before running the setup.php script. So that option will still install the database sql scripts. (as an aside it doesn't have anything to do with the new icd9 script because these are not included in installation (they are run manually after installation).
-brady
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Brady and Tony,
I understand now that this is working "as designed." and I was using the wrong option. However it is confusing, and potentially a cause of unintended data loss. I'll admit that I didn't head the warning:
"Now I need to know whether you want me to create the database on my own or if you have already created the database for me to use. For me to create the database, you will need to supply the MySQL root password.\n
<span class='title'> <br />NOTE: clicking on \"Continue\" may delete or cause damage to data on your system. Before you continue please backup your data.</span>
My loss of data was "user" error, but others (like Mukoya) may also interpret "if you have already created the database for me" the same way I erroneously did as being appropriate for a database you have already been using, and not as being for an empty database.
change to wording to "…if you have already created an empty database for me…" and one would be less likely to make the same mistake I did.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey, Frankly I rarely read these long warnings because I install new software very frequently. For example, I do not think I have ever read the warning referred to above!
I suggest then that we make it more obvious e.g a popup with sound and appropriate danger sign that one must respond to before they can continue the install process.
A better way will be to have a choice that retains the data as well.
Mukoya.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Using 4.0 I just did a merge/rebase of today's current head. When I re-ran setup and pointed it to my existing database, my codes table was empty. Perhaps this has to do with the new inclusion of icd9 codes as part of setup. It's a minor nuisance for me since I can reload my codes table in development easily enough, but I think this could be bad for people who are upgrading.
Setup, by it's nature is supposed to start clean. If you want to keep your current data after refreshing the code run the sql_upgrade.php. The easy way to know if this needs to be done is to use the url http://yoursite/openemr/admin.php - it will warn you that an data upgrade is needed and let you launch it from there.
-Tony
Hi Tony,
I have always had an issue where every time I Install the newest Dev. head (and I do that about weekly on my test machine), I lose almost all settings and data.
I resorted to exporting individual database tables e.g lists, layouts, codes, users etc. then importing them into new installation this can be tedious. I usually have to import table by table, sometimes having to first empty default installation information from tables before import can succeed.
Could you kindly expound on the steps to be taken regarding the sql upgrade.
Regards,
Mukoya
"Setup, by it's nature is supposed to start clean. "
This is not consistent with the option in setup to specify an "existing" database, especially since I wasn't upgrading, but simply pointing a 4.0 web server to an already running 4.0 database.
Consider the scenario where you want to have 2 webservers pointing at a single database instance for load balancing reasons.
You setup webserver 1 and create the database at that time. You do stuff, and then at a later time you want to build a second webserver and point it to the already existing database. If you choose "existing database" when setting up the second server, by your suggestion it's supposed to be a clean start, you'd lose things you had done on the first server.
The second server is not an "upgrade" it is a new setup, but shouldn't do anything to the data in that case.
I was expecting by running setup for the new server to simply be for specifying what database login and passwords to use, not to change data.
Furthermore. SQL_upgrade does not seem like the correct way to keep my current data as I am already on 4.0. I understand that I might not pick up needed schema changes, by using an existing 4.0 database. However, I still don't think it makes sense that setup should delete existing data.
@mukoya
I know now that I should just in the future hand edit my sqlconf.php file to accomplish what I was expecting, and you should be able to get what you want this way too. We won't get schema changes by doing it that way, but we won't have to reload our data either.
Thanks yehster.
Actually went through same issue first time, selecting the "I already have database Installed" option rather than "have setup install database". I then provided the password and all. setup completed successfully and I was shocked to find all data wiped out. At that time, I din't know about the limitation and thus had not backed up anything. It appears OEMR setup uses the credentials to log in to mysql and proceeds to overwrite all data. Only thing is it saves you another PHP/Mysql installation by using pre-existing database.
I think this is an important Issue that future development could address. For example, we could have setup warn us or give option to either retain or overwrite data as loss of data can be very expensive.
This link gives a different approach. not sure if it will help. I have not yet tried it out but as pointed out, it is a 3.2>4.0 upgrade.
https://sourceforge.net/projects/openemr/forums/forum/202506/topic/4367003
If someone already has an easy solution for this, please share.
@yehster: I am not a developer, kindly share a solution should you manage to go around the problem. It will save me a lot of time.
Mukoya
"Only thing is it saves you another PHP/Mysql installation by using pre-existing database." last post
In fact, I think this is not an issue as one might be able to manually drop database and i believe PHP will not need to be re-installed.
Mukoya.
Yehster,
The issue here is that the option your using is specific for users whom need to set up an empty shell database (ie. do not have root access) before running the setup.php script. So that option will still install the database sql scripts. (as an aside it doesn't have anything to do with the new icd9 script because these are not included in installation (they are run manually after installation).
-brady
Brady and Tony,
I understand now that this is working "as designed." and I was using the wrong option. However it is confusing, and potentially a cause of unintended data loss. I'll admit that I didn't head the warning:
"Now I need to know whether you want me to create the database on my own or if you have already created the database for me to use. For me to create the database, you will need to supply the MySQL root password.\n
<span class='title'> <br />NOTE: clicking on \"Continue\" may delete or cause damage to data on your system. Before you continue please backup your data.</span>
My loss of data was "user" error, but others (like Mukoya) may also interpret "if you have already created the database for me" the same way I erroneously did as being appropriate for a database you have already been using, and not as being for an empty database.
change to wording to "…if you have already created an empty database for me…" and one would be less likely to make the same mistake I did.
Hey, Frankly I rarely read these long warnings because I install new software very frequently. For example, I do not think I have ever read the warning referred to above!
I suggest then that we make it more obvious e.g a popup with sound and appropriate danger sign that one must respond to before they can continue the install process.
A better way will be to have a choice that retains the data as well.
Mukoya.