I may in the future be part of a shared database that would include two, possibly more, distinct databases, and I would like to have a better understanding of the limitations, if any. Currently, whenever I want to replace my database with an updated version, I stop the database, import the data into the new version, the replace the old version with the new one, and then restart the database. As part of a shared database, would I need to stop activity for all of the other databases on the server whenever I want to update mine? Or is there a way to replace my database without stopping the other databases from functioning?

Ideally you should consider using the Data Migration Tool or third party offering such as Otto. or 360 Works Deploy.

Doing manual imports you are bound to forget something - plus dependent on size it could take hours or days to complete.

The DMT was designed just for this purpose it moves the blocks where data is stored in to a clone of your file you won't have to remember to update serial numbers or other things that a straight import provides. 

 

Thanks for the information about how to migrate data without the risk and hassle of importing. I will definitely consider switching. My main concern at the moment is how to avoid having to stop the databases on the server every time I want to update to a new version and thereby interfering with the smooth operation of any other independent databases running on the same server. 

Are you saying that I can run Data Migration Tool to update to a new version without having to stop all of the databases sharing the server? 

You will have to kick all users that are using the database you are upgrading. 

From all open databases, not just mine?

All databases hosted on the server belong to the same organization. If you using your server for multi tenancy you might need to consult your license agreement.

The database that you wish to migrate with the tools mentioned before:

1. Pauses development version
2. Makes Clone of development file
3. Kicks users in production version
4. Closes production version
5. Moves production version
6. Performs migration production data > development Clone (renaming if necessary)
7. Opens/Hosts new production version.
8. Users then can resume access. ( you could kick off some script that emails or informs users system is available ) 

 

We would all be part of the same organization (a faculty within a university), and the databases would be administered by the same IT staff, but, functionally, there would be no need to stop the databases at once. Both databases would be relatively small without many users at any one time, and the code is fairly stable and so wouldn't need to be updated frequently. If all users need to be kicked out at once, we can probably accommodate that, but it's worth knowing what the options are ahead of time. Thanks for the help, Ocean.

Only the file your migrating needs to boot the users. 

Ah, great, that’s what I was hoping. Thanks again.