The Forum has been Updated
The code has been upgraded to the latest .NET core version. Please check instructions in the Community Announcements about migrating your account.
Since a couple of years Oxle is running on SQL instead of MS Access.
It's all running fine, but there's two things that have been bugging me ever since.
Me being really not savvy with SQL server technology is most likely the biggest problem here.
That's why I want to ask the following questions.
Ultimate goal of this topic is to create two in-depth howto's for both questions to be used by me and my fellow SQL Snitz users.
One: how do I make a backup? With MS Access, making a backup was easy ; just FTP to the host and download the MDB. With SQL, making a normal backup can only be done to the SQL server's filesystem, where most hostingproviders will not give you access to. So, even though I have access to the SQL server using the SQL Server Management tools and even though I can create an ad hoc backup there, I cannot access that backup. Now, the question is: how do I make an export of the SQL database that can serve as a backup to be used in disaster recovery. Which tools are required, and how do you make sure that the database structure and proper indexes are there once you import that "backup".
Two: How do I migrate my SQL database from one host(ingprovider) to another, without "native access" to the SQL server. This is so to speak step two of question one ; once I know how to export the database to a transportable format, how do I load that database on another SQL server, for instance when you switch hosting provders, or in case of a disaster recovery scenario. Again, which tools are required, and how to make sure the database structure is correct once loaded.
I assume that several howto's have been created over the years, so I might be asking for something that's already there. I certainly hope so.
One: how do I make a backup? With MS Access, making a backup was easy ; just FTP to the host and download the MDB. With SQL, making a normal backup can only be done to the SQL server's filesystem, where most hostingproviders will not give you access to. So, even though I have access to the SQL server using the SQL Server Management tools and even though I can create an ad hoc backup there, I cannot access that backup. Now, the question is: how do I make an export of the SQL database that can serve as a backup to be used in disaster recovery. Which tools are required, and how do you make sure that the database structure and proper indexes are there once you import that "backup".
Two: How do I migrate my SQL database from one host(ingprovider) to another, without "native access" to the SQL server. This is so to speak step two of question one ; once I know how to export the database to a transportable format, how do I load that database on another SQL server, for instance when you switch hosting provders, or in case of a disaster recovery scenario. Again, which tools are required, and how to make sure the database structure is correct once loaded.
I assume that several howto's have been created over the years, so I might be asking for something that's already there. I certainly hope so.
Posted
Bruno, I'll certainly ask you for help when needed. :-)
BTW, I'm not moving anywhere at the moment, however I'd like to have the plan available when I need it. Always be prepared, that's the motto.
BTW, I'm not moving anywhere at the moment, however I'd like to have the plan available when I need it. Always be prepared, that's the motto.
Posted
let me know if you need help Marcel, thoughout twitter as well, I did plenty of changes :)
Are you moving into the cloud now, or to that speedy host? Amazon EC2 seems lovely
Are you moving into the cloud now, or to that speedy host? Amazon EC2 seems lovely
Posted
I will be picking this up in the upcoming weeks. As soon as I run into things I really do not understand, I'll shout. :-)
Posted
You're welcome, Marcel .
Yes, you are right in that assumption. The SQL Server 2008 R2 client tools will connect to any SQL Server in existence (and will to upcoming ones too, but new features in these upcoming ones likely won't be seen by them). So you can use it to manage even databases on SQL Server 2000 servers. The tools also allow you to specify the version for which the database script, for example, will be generated.
For a person with no SQL Server experience, I believe a full scripting based approach may be the easiest, but in all honestly I have only used it for very small databases and I also added some code of my own to make sure that annoying things like database constraints do not interfere with the process.
If you decide to implement this, Marcel, just post any questions you may have and I will try and help with them.
.
Yes, you are right in that assumption. The SQL Server 2008 R2 client tools will connect to any SQL Server in existence (and will to upcoming ones too, but new features in these upcoming ones likely won't be seen by them). So you can use it to manage even databases on SQL Server 2000 servers. The tools also allow you to specify the version for which the database script, for example, will be generated.
For a person with no SQL Server experience, I believe a full scripting based approach may be the easiest, but in all honestly I have only used it for very small databases and I also added some code of my own to make sure that annoying things like database constraints do not interfere with the process.
If you decide to implement this, Marcel, just post any questions you may have and I will try and help with them.
Posted
Rui, this is an excellent starting point! Thank you for that!
Am I right to assume that even though you'd be using the client tools from SQL Server 2008 R2, your current SQL server does not need to be SQL Server 2008 R2 ?