I have created a database and a simple web form with couple of text-filled and a submit button in visual studio 2019(Asp.net c#). now I'm trying to save user data into the tables, since I'm not using sql server management do I still need use SqlConnection if so what is the best way to create a connecting string?
The best way to create a connection string is to write it in the Web.Config file which you will find it at the bottom of your Project in Solution Explorer.
Web.config file is basically an xml file that contains the configuration of your websites which includes your connection string.
<connectionStrings>
<add name="YourConnectionStringNameHere" connectionString="Data Source= DatabaseServerName; Integrated Security=true;Initial Catalog= YourDatabaseName; uid=YourUsernamehere; Password=Yourpasswordhere; " providerName="System.Data.SqlClient" />
</connectionStrings>
Why to write the connection string in Web.config?
You don't have to declare the connection string again and again and again in each .cs file. This is tedious. You will have one connection string at one safe place.
This is required because if some other guy handles your project and wants to change the connection name according to the requirement (in future) then it would serve a sole area as the developer don't have hassles here and there to find your connection string. This provides a clean code to understand not only you but also to other developers who will be handling your projects in future.
The SQL connection would still be required:
The SQLConnection would be required in order to connect to the database no matter whether you use SSMS or not. Even in the internal database that Visual Studio provides, you will be required to provide this connection string reference in your .cs file.
Hope this helps.
Related
I have created a web-service using asp.NET with SQL Server 2005 database. Then I published it to local IIS, but when I publish it Visual Studio showed me an error stated that:
the process cannot access the file (path to database) because it is being used by another process.
so, I Detach the database. then I published the web-service. Now, when Browsing my web-service from IIS Manager, and try to test some methods, an error page appears to say:
System.Data.SqlClient.SqlException: Invalid object name 'Student'.
where Student is a table in my database.
my connectionString is:
<add name="sbms" connectionString="Data Source=.\SQLEXPRESS;Integrated Security=True;User Instance=True" providerName="System.Data.SqlClient" />
Does Detaching the database cause this error? or there are errors in my ConnectionString? I search in Google and didn't find solution.
Please help me..
Detaching the database will cause the second error. The SqlClient can't find the table referenced by your code.
The first error comes from the database being opened in SQL Server in single user mode. Re-attach the database to SQL Server. Then change the connection settings to multiuser.
Detailed instructions for setting either single or multiple users
Sorry for the noob question. Someone has insisted me that it is possible to connect the .bak file to the asp.net website by just using connection string in the web.config only. However, I am in the midst of confusion because it doesn't make any sense to me because the .bak file is the backup file for the SQL Server.
My real question is, is it possible to connect it without dealing with SQL Server? What are the alternatives and suggestion you have?
Here's the example of web.config file he shown to me.....
<add name="accountConnection"
connectionString="Data Source=\data\websiteXl.bak; Initial Catalog=websiteXl;Integrated Security=True"
providerName="System.Data.SqlClient"/>
I have tried alternatives like using .mdf too....
<add name="accountConnection"
connectionString="Data Source=\data\websiteXl.mdf; Initial Catalog=websiteXl;Integrated Security=True"
providerName="System.Data.SqlClient"/>
This is utter crap - you cannot just connect to a .bak file, you're right (and that "someone" is plain wrong).
You will need to restore that .bak file onto a SQL Server instance, and after that's done, THEN you can use that database
No, that isn't possible. The backup file generated by SQL Server (usually with a .BAK file extension) is a compressed backup file that's not directly usable, generally.
The only thing you can really do with it is to restore the database, or make a copy of that "snapshot" of the database on another server, or the like.
There are some tools (like Red-Gate's SQL Compare and SQL Data Compare) which can show you the differences between a backup file and a live database, or between two backup files. But, that wouldn't help you connect to it through an ASP.NET page.
I have a simple ASP.NET website application. Using the new Entity Framework model-first approach, I created a database (.mdf file). However, whenever the application is running, SSMS cannot connect to the database (error 5123 or 5120), and vice versa.
Is this normal? Is there a way to get around this?
I have tried to run SSMS as Administrator, but that did not seem to help.
I am using VS 2012 Professional and SQL Server 2012 Express.
Here is the connection string of the app.
<connectionStrings>
<add name="MarketingContainer"
connectionString="metadata=res://*/App_Code.Marketing.csdl|res://*/App_Code.Marketing.ssdl|res://*/App_Code.Marketing.msl;provider=System.Data.SqlClient;provider connection string="data source=(LocalDB)\v11.0;attachdbfilename=C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQL2012ADV\MSSQL\DATA\MarketingDB.mdf;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework""
providerName="System.Data.EntityClient"/>
</connectionStrings>
When you use AttachDbFileName you place a lock to the file and use as single user mode and only one connection can use the database.
For use the database between Visual Studio and SQL Server you must:
1. Attach the database (not the file) to SQL Server
2. Use the connection string to point to SQL Server
Max answer is in principle correct. I have now implemented his answer, using this connection string
add name="MarketingContainer" connectionString="metadata=res://*/App_Code.Marketing.csdl|res://*/App_Code.Marketing.ssdl|res://*/App_Code.Marketing.msl;provider=System.Data.SqlClient;provider connection string="data source=SQLSERVERNAME;initial catalog=DATABASENAME;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework"" providerName="System.Data.EntityClient"
I should note that the reason that my problem arose in the first place was this. I use VS2012 to create an entity data model (edmx file). after I get the model to where I want it, I generate the database from model. at that point, the Generate Database Wizard shows up. New Connection. Change Data Source. I choose Microsoft SQL Server Database File (because I only had a mdf file at that point). If you do it this way, you end up with the application using LocalDB, and Attachdbfilename locks the file as Max said. However, what I should have done is first use SSMS to attach to the mdf file, and then rename the database as needed. and then in VS2012, Change Data Source, select Microsoft SQL Server instead. and now, both VS2012 and SSMS can access the database.
I can connect with the sa user via Enterprise Manager and Query Analyzer. I created the .dbml file and connection string in Visual Studio 2008 then manually imported it into the Visual Studio 2010 ASP.Net MVC3 project.
I was under the impression that this was an accepted way to work with a SQL Server 2000 database in VS 2010.
I have copied the connection string to the Web.config in the ASP.Net website.
Here is the stack trace
I'm not sure what the problem is at all. I'm hoping that it ISN'T because VS 2010 projects will NEVER be able to connect to a SQL Server 2000.
EDIT
Connection string is
<add name="MobiledbConnectionString"
connectionString="Data Source=JAMESWRIGHT2771\SQLLOCAL;Initial Catalog=mobiledb;User ID=sa;Password=MYPASSHERE"
providerName="System.Data.SqlClient" />
Obviously MYPASSHERE is where my password goes.
Not sure if it's related and perhaps a bit late but I added the option 'Persist Security Info=True' to my connection string and it did the trick.
AFAIK, the communications haven't changed -- it is quite backwards compatible. What you might try and do within the database changed quite a bit though. IE, linq to sql's schema generation might do some things that Sql 2000 doesn't like unless it has a compatibility mode for that model.
You will often get this error when the database you are accessing does not exist. Have you created it yet?
I figured out the issue, though I've never dealt with this thing before.
When I import the dbml file into VS 2010 it is being put into a "Class Library" project and for some reason it is using the Connection String that is in a "Settings.settings" file and NOT the one in the app.config or Web.config files (I verified by completely removing the Web.config and app.config Connection Strings).
I have never heard of this Settings.settings file, but I have it working at the moment by changing that value.
As I have been following a MusicStore tutorial, new MVC3 project created a following connection string for me:
<add name="ApplicationServices" connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true" providerName="System.Data.SqlClient" />
My model tables got created in .\SQLEXPRESS and all the users/roles tables are stored in the aspnetdb.mdf in the App_Data folder.
I would like to have the model tables and user/roles tables on my .\SQLSERVER or localhost rather then scattered between .\SQLEXPRESS and the mdf file. I'm struggling with the right connection string. Can anyone suggest the right one please?
Everyone who does this has to make sure that name of the connection string should be the name of the context class derived from the *DbContext*
It sounds like you need to run aspnet_regsql on your ApplicationServices database. You can find it in C:\Windows\Microsoft.Net\Framework\4.xxx\aspnet_regsql.exe.
A default project uses ApplicationServices db as default for membership, roles, and profile. The sproc dbo.aspnet_CheckSchemaVersion is a sproc in the ASP.NET SQL Membership Provider schema.
Response to comment #1
Do you have a database instance running on your machine named SQLSERVER? The exception you mentioned is a common one, if asp.net cannot find the database using your connection string.
Response to comment #2
That makes sense. Integrated Security=true tells the connection to use the process running the MVC app (usually IIS app pool) for the sql server login. If you are testing from Visual Studio / Web Developer Express / etc, the web server is likely running on a process with your windows account. So if you can windows auth against the db server, MVC should also be able to.
User Instances are meant for SQLEXPRESS.