using visual studio 2013 I created an ASP.NET MVC 5 project. I copied my database from the automatically created file to a server running MS SQL Server. However, when I created the connection string, all I specified was the ip address and the database name. It connects fine; I updated some data on the server and that data shows up. But how? I never told it the username or password I use to connect. Perhaps does Server Management Studio save that data somewhere that my application is apparently searching?
Related
I've created an ASP.NET website which runs perfectly from Visual Studio. It connects to a SQL Server .mdf database file in the App_Data folder. I published the project using FTP. The live website cannot however connect to the database, as it is LocalDB, and my host uses a SQL Server (SqlException (0x80131904))
I uploaded an identical copy of the local .mdf database file from my computer to the host's SQL Server. I then tried to form a data connection with the server database from Visual Studio, however my host doesn't allow remote database access, for security reasons, resulting in error 40.
I'm using ASP.NET MVC in my application so I need access to the database to create models. My host has said "you can access SQL Server databases using ASP scripts running on your presence".
So my question is: how do I create models based on my host's SQL Server database when remote access isn't allowed?
When you're testing with Visual Studio, you should connect to the local copy of your database. When you're ready to publish your application, copy the database to the remote sql server and attach it. The copy of your application which is published should then connect to the uploaded database on that server.
That way you have one environment for testing and one for real use. There shouldn't be any need for Visual Studio to connect to the remote database.
P.S. To allow you to connect to different databases in different environments, usually you set your database connection string in the web.config file. So if you create different config transforms for each build configuration (e.g. debug and release) then visual studio will create the correct version of the config file when you do a Publish operation. See https://learn.microsoft.com/en-us/aspnet/web-forms/overview/deployment/visual-studio-web-deployment/web-config-transformations for info about configuration transforms.
I have a situation where a classic ASP's SQL Server database has been moved from a server 2003 to a 2008r2. The classic asp application stills resides on a server 2003.
Now because I have never done a migrating the only thing I thought I needed to change is the SQL Server named IP address in the application's IIS deployed ini file. Currently I am using anonymous authentication and the default application pool. The application render's to the browser fine. The problem is the application is not pulling any data for the database.
It seems that I have missed something in the configuration process. Has someone done this type of migration and if so provide me a list of thing that they have done to configure the application correct and other settings for the migration?
Thanks,
Steve Holdorf
This is not an asp but a database authentication.
It sounds like you used Windows authentication to connect from asp to the old server. Windows authentication means that asp uses IIS user identity to connect to the database and in your ini-file (or asp files) you do not provide any user/password to connect to sql.
If you want to keep this type of authentication for the new database, then you would need to configure user on the new Sql Server. Look at the old server, you should find the user named similar to domainName\WebServerMachineName$. You would need to create the same user on the new Sql Server and grant the same rights as on the old database. Read more https://msdn.microsoft.com/en-us/library/ff647396.aspx
If this is not an issue, then you should find what is the error message when application is not pulling any data for the database.
I'm deploying a small ASP.NET (framework 3.5) application in a Windows Server Web 2008 32 bits, IIS 7. The applications needs connection to an Oracle DB in another Server, using the tradicional DataAdapter, Oracle Connection, etc.
I´ve installed correctly the Oracle Client in the server (the server is another server´s client) and I´ve checked that this server has access to the server where the database is.
Even though my app isn´t able to connect to DataBase. The message says that Oracle components haven´t been found. It doesn´t find the OleDB Provider for Oracle or some dll.
¿Something I shluod know about permissions of the ASP.NEt users or something like this?
Some idea??
Thanks in advance.
Gus.
Check the path. It could be that the Oracle client directory is not on the path of the account that runs your ASPNET app.
Actually there are other steps you can go through, to verify the Oracle client install.
This article is old but may be helpful.
I have a very simple app on my local machine that uses the ASP.NET membership provider. This works fine on my local machine.
I have published the app to our web server, and I need to know the specifics of setting up the application for asp.net membership to work.
I have a basic understanding that it uses an MDF file and somehow connects to a SQL database (SQLEXPRESS I assume on my local machine) which holds the user/role information.
I keep getting an error that it cannot connect to a SQL database when running the published application on the web server.
I wish to use a SQL server on a different machine (SQL69) than my web server (WEB69)
I have created a new connection string, but how do I tell ASP.NET to use it instead of the "LocalSqlServer" connection string that is created by default?
Can someone explain what is required to me?
Thanks for any help you can offer.
Use the ASP.NET SQL Server Registration Tool without any parameters to set up the SQL Server membership on your local machine. This will also update your config file:
http://msdn.microsoft.com/en-us/library/ms229862%28VS.80%29.aspx
You need to set up SQL Server DB membership on your local machine first. After you have this working, you can simply script the entire DB for your production environment. For this, you can use the Database Publishing Wizard in VS.
You can view a sample config file here:
http://www.codersbarn.com/post/2008/02/24/ASPNET-20-Guest-Book-Admin-Part-II.aspx
Should the ASPNETDB be left in default app folder created by Visual Studio when deploying on webserver? I have another DB that is in the mssql data folder, should that be placed in same directory as well? Im not clear on whether it matters one way or the other.
It depends what environment you are deploying your application to. Specifically, what database servers are available to you or what you are able to deploy.
If you have, or can install, SQL Server and have full administration rights over the instance then the easiest option is to attach both databases to that instance and change your connection strings appropriately. In this case both files should reside outside wwwroot, in a SQL Server specific directory.
I presume this is how the database in your 'mssql' data folder is being accessed. The connection string SHOULD NOT contain 'AttachDbFilename'.
The other option involves SQL Server Express Edition and User Instances. User Instances are created on demand to host a database when the application user does not have the right to attach it to a setup created instance. User Instances run in the context of the application user, ASPNET in your case, and lack advanced security features.
Visual Studio uses this same setup. ASPNETDB is likely using this method. The connection string SHOULD contain 'AttachDbFilename'.
A database that has been created in a user instance can be migrated to a setup instance. However, a database from a setup instance cannot be attached to a user instance because the security information is unavailable.
See Configuring ASP.NET 2.0 Application Services to use SQL Server 2000 or SQL Server 2005 and SQL Server 2005 Express Edition User Instances for further information.