data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|\aspnetdb.mdf;User Instance=true
Specifically what does
AttachDBFilename=|DataDirectory|\aspnetdb.md
mean?
It means that the connection will open aspnetdb.mdb on published app data dir.
This avoid you to read dir inside your web app once published.
Visual Studio does it automatically for you at runtime.
|DataDirectory| (enclosed in pipe symbols) is a substitution string that indicates the path to the database. It eliminates the need to hard-code the full path which leads to several problems as the full path to the database could be serialized in different places. DataDirectory also makes it easy to share a project and also to deploy an application.
For example, instead of having the following connection string:
"Data Source= c:\program files\MyApp\Mydb.sdf"
Using DataDirectory, you can have the following connection string:
“Data Source = |DataDirectory|\Mydb.sdf”
To set the DataDirectory property, call the AppDomain.SetData method. If you do not set the DataDirectory property, the following default rules will be applied to access the database folder:
• For applications that are put in a folder on the user's computer, the database folder uses the application folder.
• For applications that are running under ClickOnce, the database folder uses the specific data folder that is created.
*i forgot to add the link so here ya go ->
http://social.msdn.microsoft.com/Forums/en-US/sqlce/thread/dc31ea59-5718-49b6-9f1f-7039da425296/
*
Related
I have built an application that connects to an access database on one of my servers at work. I can easily use this on my computer but when I install on another I obviously have an issue specifying the connection to the database location on the server. How do I allow the user to specify the database connection location for use on multiple work stations? Any help is greatly appreciated!
Do not hard-code the filename of the DB in your code, rather store it in a configuration file. E.g. an INI-file or an XML-file. See How to store and retrieve custom information from an application configuration file by using Visual Basic .NET or Visual Basic 2005.
You can save the setting in the App.Config File like this.
Const connectionKey As String = "connection"
Dim config As System.Configuration.Configuration
config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None)
config.AppSettings(connectionKey) = openFileDialog.FileName
config.Save(ConfigurationSaveMode.Modified)
And you can read it again with
Dim value As String = ConfigurationManager.AppSettings(connectionKey)
(Not tested. Got it from here: Read/Write App.Config File with .NET 2.0.)
I created a software using Visual Basic 2010 and SSMS 2012 and I wish to deploy it. The question here is how should I go about doing it? I know I can create an executable file .exe which is already a good thing about VS2010 and I also think that installing SSMS-2012 as well before installing the main setup. Also, the script of the database would be generated and then run on the client's computer which enables the database to be attached. However, the question here is that should I hard-code the directory of the database files (.mdf) in Visual Basic
Currently, my connection string is such:
Server=myServerAddress;Database=myDataBase;Trusted_Connection=True;
When SSMS 2012 gets installed on any computer, the server (which is based on the computer's name) which could differ in all computers. So will this work? Or are there any other options
P.S i'm a beginner, so please go easy on me :)
if your problem only lies on the computer's name on a different pc, then try to concatenate this on your myServerAddress variable. Use
My.Computer.Name
to get the target computer's name.
This is also a good link I guess, it is an Access database though but the same concept is used (the use of DataDirectory).
I'd not suggest to hardcode the connection string as this ties your application to a very specific deployment scenario. What if a customer wants to use his or her existing SQL Server instance? What if the customer creates a named instance for the SQL Server Express installation (e.g. SERVERNAME\SQLEXPRESS). Sooner or later you'd have to change your code to reflect the different situations and you'd do the same thing that you can do already now.
In .NET, you can store a connection string in an application configuration file. It is named as the Exe file but has a .config extension (e.g. MyExeName.exe.config). In Visual Studio, all you need to do is to add a file to your project ("Application Configuration File", app.config) if it doesn't exist yet. Upon build, it will be renamed to the Exe-name plus .config. See this link for detailed information.
For your scenario, you'd have a configuration file like this. It references the local computer by using "." as the server name. So you don't have to change it after deployment if this is your default scenario:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<connectionStrings>
<add name="MyConnection"
connectionString="Data Source=.;Initial Catalog=myDatabase;Integrated Security=SSPI"/>
</connectionStrings>
</configuration>
In your code, you can access the connection string using the ConfigurationManager class (you might need to add a reference to the System.Configuration assembly). You can use the acquired connection string when you create the connection:
Dim connStr = ConfigurationManager.ConnectionStrings("MyConnection").ConnectionString
Using conn = new SqlConnection(connStr)
conn.Open()
' Use the connection
End Using
To summarize: you'd add a default configuration file with a connection string that works for any server name to your deployment. If the customer wants to have the database on a different instance or another server, you simply change the connection string - but you don't have to if the customer is fine with the default configuration. As you see, it is not much more effort than to hard code it, but it will make your deployments more flexible.
I work for a large company delivering enterprise solutions and the way we handle this is very easy. All you need is a small configuration utility (could even be your installer wizard) where you request a user credentials (which presumably have enough access right to the SQL Server to create/alter databases and objects), and for the server name.
All you need to do after that is to establish a connection to the server, create the database and run the table and/or views creation scripts.
I see you mentioned attaching an MDF file but I cannot see a reason why you would like to do that. If you have system data you still can insert it using the same script or an additional one.
I have a small vb.net application using window forms with dataset. Currently the database is stored in c:\. When I created the MSI package and installed on another workstation, I need to change the database location to a network drive z:\, but my connection string in app config is already indicated C:\ hence resulted in error.
How can I solve this?
I have an SSIS job (2008) which uses variables set up in the SSIS Configurations database table. One of these variables is the folder path which the job should look in for files.
When I have this set to a local path on the same computer it works fine, e.g. d:\Processing\
but if I change this to a network path e.g. \\networklocation\Processing, it fails with the following error
Flat File Connection Manager - Description - the flat file "\\networklocation\processing\" specified in the connection was not valid. End Error. Code 0xC001401D. Failed Validation 0xC001401E
File name property is not valid. The file name is a device or contains invalid characters.
I've read various problems about network paths and SSIS - is there a solution for it?
OK, I made a new Credential on the DB and then a new Proxy and I run the job as that user
That seemed to work ok - must have been permissions that prevented it from seeing the network folder
I have been scouring the internet for a clear answer to this question and I haven't been able to find one.
We currently have a SQL configuration enabled across packages which stores everything in a database, (dev or prod). It is a tricky process to execute packages, figuring out which configuration the packages are mapped to, and having to change them during testing. My hope is that we can use an environment variable to always use a specific connection string to the specific sql server configuration we want to use based on the machine.
I have seen ways to set up variables with the connection string hard coded as an environment variable with an additional SQL server configuration after to manage this. I have also seen ways to manipulate the connection string using XML and calling that from a variable, or from the package itself.
Both of these solutions work and very well may be viable solutions.
My question that I'm really trying to answer is; Is it possible to develop the entire SQL Server configuration connection through the environment variable? As in combining the connection string with the configuration string so that the one environment variable connects straight to the package configuration? Has anyone tried this? Does it make sense as a solution to the problem?
Yes, we have done this and it works fine. Each package has two configurations: the first is an environment variable and the second is a SQL Server table. The environment variable is the connection string for a database containing a table with all the configurations and it is applied to a connection manager. The SQL Server configuration uses that connection manager to connect to the configuration database and retrieve the individual settings.
Because configurations are applied in order, the connection string for the connection manager is set before the SQL Server configuration tries to use it. In summary:
Create your package
Add a connection manager called "Configuration Database" or whatever
Add a SQL Server configuration to the package, use the "Configuration Database" as the Connection, and choose the settings to be stored in the table
Create an environment variable such as SSIS_PKG_CONF with the connection string to be used for the "Configuration Database" connection manager
Add an environment variable configuration to the package, use the SSIS_PKG_CONF variable, and assign it to the connection string for the "Configuration Database" connection manager
Now when you run the package, the configuration proceeds as follows:
The package processes the environment variable configuration
It assigns the value of the environment variable to the "Configuration Database" connection manager's connection string
The package processes the SQL Server configuration
It uses the "Configuration Database" connection manager to retrieve individual settings from a database table
This has worked well for us because we can change the connection string to point at a different source database for the configuration, without changing anything inside the package or the launcher (i.e. the SQL Agent job or script that runs the packages). There are other ways to do it and some people feel strongly that .dtsConfig files are the better option, but we found it easier to manage environment variables than config files
But in the end managing package configurations is a preference and a lot depends on what is easier in your environment with the tools and practices you already have.