I have just installed SQL Server 2005. I was not given a choice during installation (that I remember seeing anyway) about which drive I wanted to place the default SQL instance on.
It ended up on C: and I needed it on D:.
So my questions are:
Is there a way to move it to D: that is easier than the way you had to go about it in SQL 2000?
Is there a way to do it during setup so I can avoid this in the future?
There is a file called template.ini located at the same folder as setup.exe. In this file, all related command line parameters are discussed when SQL Server 2005 is installed under unattended mode, i.e., command line. You can specify paths to install SQL Server 2005 components.
Under attended mode, i.e., GUI mode, during selecting components to install, clicking the Advanced button will prompt to change paths to install SQL Server 2005 components.
|||
Jiongxiong,
There is no file "template.ini" with the SQL setup program (cd or installed location).
The SQL readme points to a generic windows deployment info page - which is unhelpful.
|||If you're installing SQL Server Express edition you are running an executable called SQLEXPR.EXE. This is a compressed package that when run expands the contents to a temporary folder, runs the installation and then deletes the temporary folder. You can persist the uncompressed contents by running sqlexpr.exe /x - this will prompt you for a folder to save the uncompressed files. Once uncompressed you'll find the template.ini file in this folder (same folder as setup.exe). The parameters that can be passed to setup.exe can also be passed to sqlexpr.exe - the compression tool will pass the parameters to setup.exe when it runs it.
If you're installing an edition other than Express you will find template.ini in the same folder as setup.exe.
Cheers,
Dan
Jiongxiong, you are right! Sorry, I missed the template.ini file somehow. I will see if it works for my clean install tests.
It is simply amazing that M$ can not do simple file management for installation. There are files, they have versions, they need to be copied to a folder from the CD, and some settings stored - how complicated is that? Well if you are M$ you make SQL05 installation into a mass of gobble-gook. SQL Server 05 is not ready for production use until its installation abomination is fixed!
Most people think that SQL Server setup is just about copying files and writing some reg keys. While it's true it's only a small fraction of what setup does. Here is a small sampling of the other things SQL Server setup does.
SQL Server setup checks the configuration of the machine to determine if the machine is in a valid state - which improves the chances of a good installation. Windows Installer doesn't support this.
SQL Server is a multi-instance product. Windows Installer doesn't support this.
SQL Server requires configuration to happen as part of the setup process. Windows Installer doesn't support this. If you've ever performed a MySQL installation a separate tool is launched post setup to do the configuration - although at the end of setup you don't have a working server.
SQL Server cluster install is extremely robust. Every other product I've seen requires you to rerun setup on every node and make sure the configurations are the same. SQL does this for you. Windows Installer doesn't support cluster installs.
SQL Server requires a secure installation. This means that every file/directory/service/reg key is ACL'd to the appropriate service account. Windows Installer doesn't support this.
SQL Server setup supports version and edition upgrade. Windows Installer doesn't support this.
Windows Installer handles very well the copying of files and the writing of reg keys, but it doesn't handle any of the other complexities associated with SQL Server setup. Everywhere I mentioned that Windows Installer doesn't support something it means we've had to build it. I'm not using this as an excuse, but merely highlighting the fact that setup is much more than just copying files and writing reg keys. Anyone who's worked on the setup of a complex product (such as SQL or Visual Studio) will attest to this.
Is our setup perfect? No. But I certainly don't believe it deserves the criticism. There are millions of ways a user can hose their machine and it would be impossible for us to test for every single case. I'm sure you'll be tempted to compare SQL with other products - don't. There are very few products that come to mind that have the same level of complexity that SQL Server does. Again, this is not an excuse for any particular bug that remains in setup. The complexity of SQL Server has grown tremendously from SQL Server 7.0. The setup has had to embrace the increased complexity and deliver a stable and consistent experience. I believe this was achieved.
Cheers,
Dan
Dan:
This is critical tidbit that surely belongs in Embedding SQL Server Express in Custom Applications. That's a 32-page article (from November 2005) at the Microsoft SQL Server Developer Centre, and while it obviously spends time on template.ini, it doesn't tell you how to find it. Luckily for me, I found your reply on this forum.
Please pass this on to Robert Walters, who wrote the article.
Regards
Josh Korn
