Choosing connectionstring in VB.NET application at startup - sql-server

I have a VB.NET application with a connection to an SQL Server 2003. On the server there are two databases, MyDatabase and MyDatabase_Test. What I would like to do is to show a dialog when the program starts that let's the user choose which database to use. My idea is to create a new form as the starup form that sets this property and then launches the main form.
Currently the connectionstring is specified in the application config file. Best would be if I can specify two different connection strings in that file to choose from, but for now it is also acceptable with other solutions like hardcoding the two connectionstrings into the startup form.
EDIT: In the dataset.xsd file there seems to be the relevant part
<Connections>
<Connection AppSettingsObjectName="MySettings" AppSettingsPropertyName="MyDatabase_ConnectionString" ConnectionStringObject="" IsAppSettingsProperty="true" Modifier="Assembly" Name="MyDatabase_ConnectionString(MySettings)" ParameterPrefix="#" PropertyReference="ApplicationSettings.MyProgram.My.MySettings.GlobalReference.Default.MyDatabase_ConnectionString" Provider="System.Data.SqlClient" />
</Connections>
But how do I change it at runtime? The closest i could find is changing which connection is used for every single TableAdapter but that doesn't seem very optimal.
EDIT2: I agree that a modal dialog at startup would be better, but where would i launch it so that it is done before the database connection is initiated?
EDIT3: Eventually I "solved" it by removing the ReadOnly from the settings file. This will be removed each time the file is auto-generated though, so it's not optimal.
EDIT4: A better solution seemed to be using a user scoped string instead of a connection string to link the dataset and fetched the value for that string from the two application scoped ConnectionStrings.

You could just set the TableAdapter.Connection.ConnectionString property right before you use it every time.
Find the section in your app.config which defines the connection strings and add another:
<connectionStrings>
<add name="Live"
connectionString="Data Source=svr;Initial Catalog=Live;..."
providerName="System.Data.SqlClient" />
<add name="Dev"
connectionString="Data Source=svr;Initial Catalog=Dev;..."
providerName="System.Data.SqlClient" />
</connectionStrings>
on startup, populate a global variable that reads out of one setting or the other based on the users choice

After some more consideration hacking the settings file to remove the ReadOnly property seems like the best solution.
It is not possible to define a ConnectionString at the user scope, only at the application scope. It is possible to use a string instead of a ConnectionString, the program will run fine, but it causes a lot of IDE issues and Visual Studio exceptions during the auto-compiling.

I don't understand the question, or rather I can't see any question.
Are you having any specific problems with doing this or just wondering if it's an ok design?
Having multiple connection strings in the config file and then choosing between them at startup should work fine. The only thing I might do different from how you describe it that I'd probably keep the main form as the startup form and then do something like pop up a modal dialog box straight away where the user selects the connection.

Related

Universal Windows Platform (UWP) and SQL Server

I've hit a wall when it comes to how the Universal Windows Platform connects/manages/interacts with a local SQL Server database. My current project (WPF using .NET Framework 4.8) that I'm interested in porting over to UWP uses EntityFramework 6 with ADO.NET models and it works like a charm. No issues at all. UWP on the other hand, well I'll just say that I have absolutely no idea what's going on when it comes to connecting to a local instance of SQL Server. I've gone through about 3-4 different guides/templates and none have worked. I really want to use UWP and take advantage of all the new features coming for Windows 10 v2004, but it doesn't look like this will happen.
As I currently understand the process, I need to essentially create two separate projects within the same solution. One is the UWP main program and the other would be a .NET Core class library that targets the .NET Standard 2.0 platform. I also have read that EntityFramework 6 is not supported on .NET Core or UWP, so the only way is by using EntityFrameworkCore (more specifically NuGet package Microsoft.EntityFrameworkCore.SqlServer). So I installed it on the .NET Core class library and then set a reference from the UWP app to the class library. Because the local SQL Server is already up and running, I'm not doing what is called the 'code first' approach to the creation of all the models/DbContext.cs files. Based on what I've read, the ONLY way to import a currently existing SQL Server into the data model is by use of the Scaffold-DbContext command with a standard connection string through the package manager. Surprisingly, this worked on the first attempt and the models and DbContext were all created without any issues.
This is about as far as I seem to be able to get as everything after does nothing but throw exceptions. If I try to pass any C# code using the DbContext to retrieve any data from the database, I get about 10-15 exceptions that essentially say the program can't find or connect to the database. I have manually edited the connection string in every way imaginable, but nothing seems to work. I also tried to manually set up a new connection using Microsoft.Data.SqlClient.SqlConnection, Microsoft.Data.SqlClient.SqlConnectionStringBuilder and System.Data.SqlClient.SqlConnection but they all fail with the same exceptions.
Sorry for the long post but at this point, I really don't know what's going on and would really appreciate any feedback you all could offer.
Update 1
So, I went back through my currently working app on .NET Framework and looked for the connection string in the App.config file to see what the regular EntityFramework is using and it's completely different than anything I've used before. My guess is that it's generating a completely custom connection string that includes references to all sorts of files and a property called 'ProviderName'. Will try cutting and pasting this string into UWP to see if it'll work.
Update 2
I think I'm missing something fundamental on this. I can generate the scaffold with a connection string without any issues, but if I attempt to open a connection at runtime using the same connection string, I'm getting errors.
Finally was able to get a connection at runtime after months of trial and error. Without getting into too much detail, here's what worked for me (assuming EFCore has already generated a DbContext file):
Enable Enterprise Authentication.
Enable TCP/IP connections to the SQL Server instance.
In Visual Studio's server explorer, click Add Connection. If you already have a connection saved for the database, right click the server and click Modify Connection
In the connection properties window, click the Advanced button. Make a note of all of the listed parameters and their values and save it.
Open the data context file that isn't able to connect and add a using statement for Microsoft.Data.SqlClient. Now locate the OnConfiguring method. Use a SqlConnectionStringBuilder and configure all of the parameters from the advanced connection properties that were saved earlier.
And that should work. If there are still errors, I would double check the parameters to make sure they were all entered correctly.
Hope this post will help out anyone else dealing with this issue.

No connection string named 'MyApplicationEntities' could be found in the application config file

I just install EF 4.3 and trying to upgrade my project with migration. however I am getting issues with trying to execute add-migration initial to my project via Package Manager console.
It is throwing any exception now No connection string named 'MyApplicationEntities' could be found in the application config file.
Now my config has it all
<connectionStrings>
<add name="MyApplicationEntities"
connectionString="metadata=res://*/DataModel.csdl|res://*/DataModel.ssdl|res://*/DataModel.msl;provider=System.Data.SqlClient;provider connection string="data source=localhost;initial catalog=MyApplicationEntitiesDB;integrated security=True;multipleactiveresultsets=True;App=EntityFramework""
providerName="System.Data.EntityClient" />
I am not sure what is the issue is it a bug in EF 4.3 or there is something I am not doing right.
I thought this post has solved the issue but not quite.
Anyone got an answer.
Appreciate Sanj.
Ah, figured this out accidentally.
I had to remove
public MasterEntities()
: base("name=MyApplicationEntities")
// ^^^^^
{
}
to
public MasterEntities()
: base("MyApplicationEntities")
{
}
EF 4.3 does not like connection string being called name=xxxxx
The solution as Sanj pointed out is that you need to copy the connection string from your database project's App.config to the web project's web.config. I'm not sure why the above answer is marked as correct. I'm adding this as an answer instead of a comment so future readers will spot this.
I had the same error but I already had a web.config file with the correct connection string name and a DbContext declared correctly. However, I noticed when I ran add-migration with -Verbose it state the 'Startup Project' as a different project than the one containing my context. So I change the Startup Project, re-ran the add-migration and it all worked!!
Make sure your statup project config file has the connection string.This link may help you.
I also had this problem and solved it by
Selecting the correct StartUp project.
Rerunning the command on Package Manager Console.
Things worked out as expected.
I also encountered the similar exception. AppConfig is originally gets created in the project that we generate the entity model.
But if you are executing the application using some other project (there are several Projects in my solution), the AppConfig needs to be included in the project which is being executed.
1. ctor => Context
public MasterEntities()
: base("ConnectionStringName")
{
}
2. config file
<add name="ConnectionStringName"
connectionString="Data Source=.;Initial Catalog=DatabaseName;User Id=sa; Password=YourPass;"
providerName ="System.Data.SqlClient" />
3. in Sulation Exporer right click the project and select 'Set as
startup project'
4. in PackageManagerConsole Change Default Project to Your Project of
context class.
5. then:
add-migration new
or added ConnectionString to config file of working Project.
In my case, i got two projects:
I just have to copy the connection string from DAL App.Config project to WPF App.Config project
If you get this error and you're working with Oracle DBs in .NET, check your existing <connectionStrings> tag in the startup project (web.config in web projects, app.config in console/Windows projects), and make sure Oracle didn't replace it with nonsense.
Installing the Oracle.ManagedDataAccess.* assemblies from NuGet does this obnoxious thing where it deletes whatever <connectionStrings> tag that already existed in destination project and replaces it with a new one at the bottom containing a boilerplate Oracle connection string.
Do a git diff or whatever you use to diff changes and focus on your *.config files. Restore old connection strings as needed, then rebuild and try again.
For all others, just remember that the <connectionStrings> tag is only read from the startup project's configuration (aka the entry assembly). If you have your DB stuff in another project that is referenced by your startup project, and you have an app.config in that DB project with a <connectionStrings> tag in it, that tag is only used for for scaffolding EF stuff. After that, the DB project reads the tag from the startup project's configuration instead of its own.
For anyone arriving here because they are getting this error while working with WPF in Visual Studio, please take a look at this post:
Does MVVM stop the ability for the Visual Studio Designer to show xaml?

How data sources are linked in compiled Visual Basic .NET applications?

When I try adding a new data source to my project I get a prompt saying "The connection you selected uses a local data file that is not part of the current project. Would you like to copy the file to your project and modify the connection?"
This sounds rather obscure to me, as I'm new to VB.NET and programming non-script apps in general. The data source in this case is a .sdf SQL CE file.
Question 1: If I say that I want to copy the database to the project, what will happen after I compile the app, where the database will be? (how will I edit it from another app?)
Question 2: If I do not include it, how the data source will still keep linked? Can I link using filesystem enviroiment variables like %ProgramFiles%\MyAppDir?
Question 3: Can I just tell it to use a read-only (Just needs to read it) data source on the web, like on an FTP?
Thanks for help in advance! =)
Visual Studio just tries to have all your files in one place, with the rest of them - in project folder.
Q1 - SQL Ce database can be anywhere you like, you use ConnectionStrings settings section in your app.settings. SQL Ce is just a file, nothing more, nothing less, therefore accessible from any application. Is is not compiled into your app, it just travels with it when you deploy etc.
To answer Q2 - you probably can, but I'm not sure that it will work automatically for you.
Q3 - to read from ftp, probably not, unless you work ftp client support into your app and download it in background. Another solution would be to map ftp to local drive and access it from there.
For example, storing connection string in app.config (excerpt from app.config):
<connectionStrings>
<add name="db" connectionString="Provider=Microsoft.SQLSERVER.OLEDB.CE.2.0; data source=c:SomePathToSDFfile" />
</connectionStrings>
Later in your application, you access this connection string like this:
(add reference to System.Configuration)
Dim c As Configuration.ConnectionStringSettingsCollection
Dim cn As SqlClient.SqlConnection
c = Configuration.ConfigurationManager.ConnectionStrings
cn = New SqlClient.SqlConnection
cn.ConnectionString = c.Item("db").ConnectionString
cn.Open()

linq to sql Insert not working on deployed server(IIS)

title speaks for itself,
db.ExecuteCommand("INSERT INTO tCSVFile(fileName, fileContent, mimetype, timeCreated) VALUES({0}, {1}, {2}, {3})", filename, EncodeTo64(CreateCSVFile(header, rows)), "text/csv", DateTime.Now );
this works fine from the virtual server but on iis inserting causes nothing to happen.
Also tried this..
tCSVFile c = new tCSVFile
{
fileContent = EncodeTo64(CreateCSVFile(header, rows)),
fileName = filename,
mimetype = "text/csv",
timeCreated = DateTime.Now
};
db.tCSVFiles.InsertOnSubmit(c);
db.SubmitChanges();
again works on virtual server but on iis no luck. any help would be greatly appreciated as i have looked on the web and havent found anything of use. My selects work fine and can select without a problem.
Connection string is
<add name="db_ac_motors_testConnectionString" connectionString="Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\db_ac_motors_test.mdf;Integrated Security=True;User Instance=True"
providerName="System.Data.SqlClient" />
The insert is a call from a MVC Partial view and is done through ajax.beginform()
Are you certain the database is attaching correctly. Many ISPs have it set up so you cannot attach a database using the connection string methdology you have employed. That is the first place you should look. I would think you would get an error, but it might be swallowed up somewhere in the stack.
If you need to move SQL to a SQL instance (not SQL Express necessarily) rather than attach, this might help:
http://gregorybeamer.spaces.live.com/blog/cns!B036196EAF9B34A8!630.entry?sa=214268831
What does the function/method CreateCSVFile() do? If it writes files to the filesystem then it looks like you have a permissions problem. i.e. The anonymous user for the site may not have write permissions.
Just a thought.
Kev
After finally spending couple hours looking for some sort of exception I saved the stack trace in an event log and found this error
System.Data.SqlClient.SqlException: Failed to update database "(database directory)" because the database is read-only.
So with some fishing around the internet it had to do with a user permission restriction.
here is a link if anyone runs into the same problem. I guess the debugging virtual server reads folder permissions differently hence the restriction only on deployment(IIS is a little fussy when it comes to permissions). And I was surprised that no exception was being returned...I had to do so much to access the stack trace, I don't want to even begin... Anyways the link is this just follow the steps and it should point you in the right direction.
http://social.msdn.microsoft.com/forums/en-US/sqldataaccess/thread/2e776fb4-6df9-4a11-96f1-948b8a2f839a/#page:2

Can connectionstring cross over to other sites on the same server?

I ran across a new problem in the last week. Due to the nature of my project and available budget a small intranet web application I've been working on is both the testing and live server, as well as serves up the pages and is the sql server. This will last at least until the project is out of the major development cycle. Now that the project has real users but I am continuing development I duplicated the database to have a safe copy to mess with that won't cause havoc to live business data and a development copy of the website.
All was well until I discovered an anomoly on the test copy of the site, anything that uses a sql datasource was properly pulling it's data from the test database, but anything that gets it's data from a stored procedure triggered in the code behind was pulling it's data from the live databse.
My confusion comes from the fact that all stored procedures and sql datasources ultimately point back to the same connectionstring setting in the web.config file to know where to connect to. I just rename the database name depending on if I'm uploading the latest changes to the test or live site.
My question comes down to, why would with one connection string in each site would my test site accessing data one way get it from one database and accessing the other get it's data from the other database?
Here's my connection string they all point back to, names/passwords of course change for obvious reasons, but the structure is intact.
<add name="db_Connection" connectionString="Data Source=SERVERNAME;Initial Catalog=DATABASE_live;Persist Security Info=False;User ID=USERID;Password=password" providerName="System.Data.SqlClient"/>
I added a key to the appsettings to reference the name of the database connection so I could easily change it's name if need be without having to edit dozens of pages for the code behind SProc calls.
<add key="defaultDB" value="db_Connection" />
Am I violating some rule I'm unaware of or is there something else going on that I need to be aware of and change so I can have a true test environment as I continue to develop an active site?
EDIT This project is in ASP.NET 2.0 VB, fixed the code display.
solution found I have tracked down the solution, thanks for the pointers, they got me looking elsewhere. When I copied the site to a different location for testing I forgot to update my appsetting key for the site's location, this caused the following part of the call for stored procedures to grab data from the live site's web.config aparently.
System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration(pubvar_webConfig)
Change the username and password on the dev database. If your problem persists then you might have a connection string set somewhere else that you don't know about.
I would search all of the files in your solution to make sure you don't have one of the database names hard coded some place. Maybe in the designer files?
It may be worth running the two applications in different app pools via IIS (if you aren't already or course!). This should eliminate any concurrency issues between the test and production sites at the application level.
IMHO with a shared test / production environment seperate app pools is good practice at any time.

Resources