databinding, differently named sql server?

[RegJ]

Hi everyone,

My first post here, please be patient!!

I am developing my first winforms application using VS2013 and SQL Server 2014.

I've been reading about binding form controls to a datasource, and I understand about creating project data sources. My question is, if I create a data source to my development SQL Server and use it for binding, what happens when I deploy my application to a customer who has a differently named sql server? Won't the binding fail?

Cheers
Reg

 

[Herman]

You should use a BindingSource for this. You bind the BindingSource object to the controls, and your datasource to the BindingSource.

 

[RegJ]

RE: databindingquestion

You should use a BindingSource for this. You bind the BindingSource object to the controls, and your datasource to the BindingSource.

Hi, yes sorry I have not made myself clear. I can see how to use the BindingSource, but then that is linked to the data source and the same question still applies; would this link not work once the datasource becomes invalid upon deployment?

 

[jmcilhinney]

There's no issue. The Data Source really just maps the database schema to .NET objects, e.g. your DataSet will contain a DataTable for each table in the database and each of those will have a property for each column. You'll also have a table adapter for each DataTable that contains the connection to the database and the SQL to move data back and forth.

When you deploy your app, you simply change the connection string to point to your production database and, as long as it has the same schema as the one you used in development, it will just work. In fact, depending on the specifics of the database, you might not even need to change the connection string. If you have a data file in the same folder as the EXE then the connection string can contain a relative location and will just work after deployment.

For instance, let's say that you add a Service-based Database item to your project, which means a SQL Server Express MDF file. Your connection string will look something like this:

Data Source=.\SQLExpress;AttachDbFilename=|DataDirectory|\MyDatabase.mdf

The "|DataDirectory|" part is going to resolve at run time to the path of the folder the current EXE was run from so, as long as the EXE and the MDF file are in the same folder, it doesn't matter where that folder is. As for the Data Source, the dot means the local machine so it will work on any machine with an instance named SQLExpress, which is the default name for any SQL Server Express instance.

The connection string is stored in the config file so you can always change the instance name there if you need to, either before or after deployment. The database name is unlikely to change but you can alter any aspect of the connection string if required. As long as the database is the correct type and schema, the app doesn't care where it is.

 

[RegJ]

There's no issue. The Data Source really just maps the database schema to .NET objects, e.g. your DataSet will contain a DataTable for each table in the database and each of those will have a property for each column. You'll also have a table adapter for each DataTable that contains the connection to the database and the SQL to move data back and forth.

When you deploy your app, you simply change the connection string to point to your production database and, as long as it has the same schema as the one you used in development, it will just work. In fact, depending on the specifics of the database, you might not even need to change the connection string. If you have a data file in the same folder as the EXE then the connection string can contain a relative location and will just work after deployment.

For instance, let's say that you add a Service-based Database item to your project, which means a SQL Server Express MDF file. Your connection string will look something like this:

Data Source=.\SQLExpress;AttachDbFilename=|DataDirectory|\MyDatabase.mdf

The "|DataDirectory|" part is going to resolve at run time to the path of the folder the current EXE was run from so, as long as the EXE and the MDF file are in the same folder, it doesn't matter where that folder is. As for the Data Source, the dot means the local machine so it will work on any machine with an instance named SQLExpress, which is the default name for any SQL Server Express instance.

The connection string is stored in the config file so you can always change the instance name there if you need to, either before or after deployment. The database name is unlikely to change but you can alter any aspect of the connection string if required. As long as the database is the correct type and schema, the app doesn't care where it is.

Ah, I see, the config file was the missing link in my understanding. Thanks