Problem With Saving Data To SQL Database After Installation

Peter

Hi,

So I'm developing a program in Visual Studio 2010 that uses an SQL Database to save data from the program. I added a Visual Studio Installer to the project for a more professional installation, however I'm not really sure of the proper to add the databases to the installer.

Here is the problem:

I can add the database's .mfd file and the database's log file (I can find both of these in the debug folder of the project file). However if I just add them to the installer it will install them to the program folder. The problem is that in Windows 7 all files within the programs folder are read only, so the program cannot edit the databases at all.

How can I install them to a different location and how do I make my program find the databases if they aren't in the same folder as the application (I have tried moving the database files, but my program won't find them unless they are in the same directory as the .exe file for my program)?

Any and all help is appreciated.

3 Replies

Know the answer? Post it — somebody with the same question will find it here.

Zoran Horvat16y ago
But why would you put database into installation package? It is certainly easy to deploy database file, but what would be the purpose of that?
0
Hirendra Sisodiya16y ago
Hello Peter

you can do that easily , i will tell you tomorrow because today is very busy for me.....
0
Zoran Horvat16y ago
You shouldn't add database to installation, except if it is pre-filled with too much data and/or binary data. Even in those cases, carrying database file is not a good idea because version of database engine may be older than yours, you still have to manage user privileges programmatically, etc. So other solutions should be seeked.

Proper way is to include database creation and initialization script into setup. Then, during the installation, new database would be created on the target system and initial load would be done. In this way, you can modify the process by selecting database name on the spot, then creating user(s) with required permissions, scheduling automatic backup, etc.

That is more flexibile way to do the thing. It is capable to support multiple versions of database engine, including older ones which is always the problem. Further on, in an extreme case, you may also support multiple database engines, like SQL Sever and MySql at the same time (which is rarely needed, but happens) if you happen to use only 100% compatible features of the engines.
0