How to allow others to run Web App using LocalDb - asp.net-core

I have created this assignment where I am essentially using .net Core to read and write to an instance of a SQL localDb: Github
This is my first time using a localdb, but when I submitted it to my professor, he is not able to create, or manipulate the database at all. My thoughts were that when he runs it, it would create and instance of the database on his computer, but I guess not. He gets the following error:
SqlException: Cannot open database 'Bartender_App' requested by login. The Login failed. Login failed for user "Username"
this error occurs when trying to create a new order. Is there any way to bypass this authentication? because the web app works on my computer.
would he have to create his own migrations and update the database from Visual Studios on his end?
I have tried to look it up, but come across deployment of these web apps to a server which is not what I am trying to do, I am just aiming for him to be able to run the application on his computer, even if the database starts empty, and he can manipulate, add, and remove the data from the localDb instance
I apologize in advance for the tags - the autocomplete feature was not showing up correctly.

Is there any way to bypass this authentication? because the web app
works on my computer.
This is impossible, SQL Server Express LocalDB does not accept remote connections.
As an alternative, you can automate the backup of your database structure and provide it to your instructor, you can refer to How to copy a database from one computer to another?.
If there is not much table, manual creation may be faster and easier.
More details ,have a look for Can SQL Server Express LocalDB be connected to remotely?.

Related

How to connect to a SQL Server from an m1 chip macbook

I am working on a project with a friend and he has deployed a SQL Server database. He uses a PC and can access the database using Microsoft SQL Server Management Studio (SSMS).
However I have a Macbook with an M1 chip and so I cannot use SSMS and need to figure out which SQL Server application I want.
It seems like the way to go is Microsoft Azure Data Studio. I cannot figure out how to connect properly, I have looked at several solutions posted online which all say to download docker, download the latest SQL Server image, use SQL edge, run SQL Server in a container and then open Azure and connect.
One caveat is that all these tutorials end with creating a SQL Server on the local host rather than connecting to an existing one.
In Azure, after entering server id, username and password, there is a green dot on the label of the DB on the left drop down menu, indicating that the connection to the DB was successful. However whenever I try to view the DB's from the drop down it loads and then errors:
Object Explorer task didn't complete within 45 seconds
and I cannot run any basic queries either.
At this point I don't care what IDE I use as long as it works. Any advice is much appreciated. It seems like this task should be super easy but has given me such a hard time and we cannot continue working on the project until I get access.
Anyways, thanks again in advance! and lmk if there's any other info I should provide.
Tried using docker with Azure Data Studio and my results were the same as when I only used Azure.
You'll want to use Azure Data Studio.
You don't need Docker at all to meet your goals. Those tutorials were in regards to running your own SQL Server instance on a Mac. You're trying to connect to an existing instance.
As mentioned in the comments, where is the existing SQL Server instance located?...is it on a server that's part of a domain. Is your Mac part of that same domain? It sounds like you're getting some kind of timeout issue or some sort of authentication issue. So this is more of an infrastructure question.
Once connected to the SQL Server instance in Azure Data Studio, what happens if you just open a blank worksheet and run the query SELECT ##SERVERNAME?

IIS connecting to LocalDB

Is there any way so IIS could connect to LocalDB without using the NT SERVICE\NETWORK SERVICE user account.
This account has not suitable permissions. I'm looking use some other default account or is there some way that I can use the NETWORK SERVICE account without changing permissions?
You should use Shared Instances feature of LocalDB. These two posts on Using LocalDB with Full IIS should give you more information. Especially the second part seems relevant, but the first one contains some context as well.
(note: the original links are no longer available, using archive.org instead)
Part 1: User Profile
Part 2: Instance Ownership
Original (non-working as of March 2019) links:
Part 1: User Profile
Part 2: Instance Ownership
In case the links disappear again, I am copy-pasting solutions from the article for easier access:
Post 1:
The problem we're facing is that the user profile needs to be loaded. That shouldn't be hard since each IIS Application Pool has an option called Load User Profile that can be found in Advanced Settings section. Unfortunately things got slightly more complicated in Service Pack 1 for Windows 7. As described in KB 2547655 enabling loadUserProfile is not enough to fully load user profile, we also need to enable setProfileEnvironment. This requires editing applicationHost.config file which is usually located in C:\Windows\System32\inetsrv\config. Following the instructions from KB 2547655 we should enable both flags for Application Pool ASP.NET v4.0, like this:
<add name="ASP.NET v4.0" autoStart="true" managedRuntimeVersion="v4.0" managedPipelineMode="Integrated">
<processModel identityType="ApplicationPoolIdentity" loadUserProfile="true" setProfileEnvironment="true" />
</add>
Having completed that we restart the Application Pool to make sure the new settings are applied and run our Web Application again.
Note from my side: Just find "applicationPools" tag in that applicationHost file and update those two variables to true, so it looks like this:
<processModel identityType="ApplicationPoolIdentity" loadUserProfile="true" setProfileEnvironment="true" />
That's it, save the file and restart IIS pool.
Post 2:
The Problem of the Private Instance
As we can see we are facing the following error:
System.Data.SqlClient.SqlException: Cannot open database "OldFashionedDB" requested by the login. The login failed.
Login failed for user 'IIS APPPOOL\ASP.NET v4.0'.
This time the error is quite clear. LocalDB was started and the Web Application was able to connect to it, but the connection was then terminated due to login failure. The ApplicationPoolIdentity account for the IIS application pool (in this case IIS APPPOOL\ASP.NET v4.0) couldn't login to LocalDB instance because the database specified in the connection string (OldFashionedDB) wasn't found. How odd, since connecting from Visual Studio with the same connection string succeeds!
How is it possible that Visual Studio connects to LocalDB just fine, while the connection from Web Application fails? In both cases the connection string is the following:
Data Source=(localdb)\v11.0;Initial Catalog=OldFashionedDB;Integrated Security=True
The answer is that there are two different LocalDB instances here. Unlike SQL Server Express instances, which are running as Windows services, LocalDB instances are running as user processes. When different Windows users are connecting to LocalDB, they will end up with different LocalDB processes started for each of them. When we connect to (localdb)\v11.0 from Visual Studio, a LocalDB instance is started for us and runs as our Windows account. But when Web Application, running in IIS as ApplicationPoolIdentity, is connecting to LocalDB, another LocalDB instance is started for it and is running as ApplicationPoolIdentity! In effect, even though both Visual Studio and Web Application are using the same LocalDB connection string, they are connecting to different LocalDB instances. Obviously the database created from Visual Studio on our LocalDB instance will not be available in Web Application's LocalDB instance.
A good analogy to this is My Documents folder in Windows. Say we open Visual Studio and create a file in our My Documents folder. Then we login to the same machine as a different user and go to My Documents folder again. We won't find the file there as My Documents of the second user and our My Documents are two different folders. Similarly LocalDB instances (localdb)\v11.0 owned by two different users are two different processes with two different sets of databases.
This is also the reason the Web Application was able to connect to LocalDB from IIS Express. Just like LocalDB, IIS Express is a user process. It is started by Visual Studio and runs as the same Windows account as the Visual Studio process. Two different processes running as the same Windows account (Visual Studio and IIS Express, both running as our Windows account) connecting to (localdb)\v11.0 are connecting to the same LocalDB process, also started as the same Windows account.
Possible Solutions
Understanding the nature of the problem brings multiple approaches to solving it. As different approaches have different tradeoffs, instead of prescribing one solution, below I presented three approaches that seem most viable to me. My hope is to hear from you about the one that worked best for you! Here is the list:
Approach 1: Run IIS as our Windows user
Approach 2: Use LocalDB Shared Instance
Approach 3: Use full SQL Server Express
Let's take a closer look at each of them.
Approach 1: Run IIS as our Windows user
If different user accounts are the problem, why not try to run our Web Application under our Windows account? Web Application would connect to the same LocalDB as Visual Studio and everything should just work.
Making the configuration change is relatively easy, just start IIS Manager and find the right Application Pool:
Open Advanced Settings screen (available in the context menu):
Click the little button in the Identity property to bring up the Application Pool Identity screen:
Starting the Web Application again will confirm that the problem is solved:
What are the drawbacks of this approach? Of course running Web Application under our account brings certain security risks. If someone hijacks our Web Application they will be able to access all system resources our account can. Running the Web Application as ApplicationPoolIdentity provides additional protection since ApplicationPoolIdentity accounts have very limited access to local system resources. Therefore I cannot recommend this approach in general, but when used with care it is a viable option in some cases.
Approach 2: Use LocalDB Shared Instance
We could also use an instance sharing feature of LocalDB. It allows us to share a LocalDB instance with other users on the same machine. The shared instance will be accessible under a public name.
The easiest way of sharing an instance is to use SqlLocalDB.exe utility. Just start an administrative command line prompt, and type the following command:
sqllocaldb share v11.0 IIS_DB
It will share the private LocalDB instance v11.0 under the public name IIS_DB. All users on the machine will be able to connect to this instance, using (localdb).\IIS_DB as a server address. Note the . before the instance name, indicating this is a shared instance name. We should replace the connection string in our Web Application with an updated one:
Data Source=(localdb)\.\IIS_DB;Initial Catalog=OldFashionedDB;Integrated Security=True
Before the shared instance can be used by the Web Application we need to start it and create logins for the ApplicationPoolIdentity. Starting the instance is easy, simply connecting to it from SQL Server Object Explorer will start it and keep it alive. Once we are in the SQL Server Object Explorer we can also create the login for ApplicationPoolIdentity. We could use the following query:
create login [IIS APPPOOL\ASP.NET v4.0] from windows;
exec sp_addsrvrolemember N'IIS APPPOOL\ASP.NET v4.0', sysadmin
This script gives full administrative access to our LocalDB instance to the ApplicationPoolIdentity account. Whenever possible, I would recommend using more limited, database-level or even table-level permissions.
Now we can run our Web Application again. This time it should work just fine:
What are the drawbacks of this approach? The main one is that, before Web Application can connect to the shared instance, we need to make sure the instance is started. For that to happen the Windows account that owns the instance must connect to it and the connection must be kept open, or the LocalDB instance will shut down.
Approach 3: Use full SQL Server Express
Since full IIS runs as a service, maybe using traditional, service-based SQL Server Express is the right approach? We could just install SQL Server 2012 Express RC0 and create the OldFashionedDB database in it. We can even use our brand new SQL Server Data Tools to do it, as it works with any SQL Server version and edition. Our connection string would have to change to:
Data Source=.\SQLEXPRESS;Initial Catalog=OldFashionedDB;Integrated Security=True
Of course, just as in the previous case, we would need to make sure the ApplicationPoolIdentity account has access to our SQL Server Express instance. We can use the same script as previously:
create login [IIS APPPOOL\ASP.NET v4.0] from windows;
exec sp_addsrvrolemember N'IIS APPPOOL\ASP.NET v4.0', sysadmin
After that, running our Web Application brings the happy picture again:
What are the drawbacks of this approach? Obviously we lose the benefits of using LocalDB. Installing SQL Server Express may take more time than LocalDB, and there may be some machine cleanup necessary for it to succeed. SQL Server Express Setup can be blocked by problems like corrupt WMI database, polluted registry or components left by SQL Server or Visual Studio CTPs and Betas. And SQL Server Express will continue running in the background even when not needed, as services do.
Other options
There are other approaches of using LocalDB under full IIS that are not covered here. We could embrace the Web Application's private LocalDB instance and communicate with it through the Web Application by executing T-SQL scripts from ASP.NET code. We could also use AttachDbFileName option of ADO.NET connection strings and use a database file (.mdf) that would be attached to both our LocalDB during development and Web Application's LocalDB for debugging. I tried both I found them too cumbersome to discuss further.
Based on the answer from #KrzysztofKozielczyk.
I originally posted an answer here:
https://stackoverflow.com/a/62810876/3850405
After following this I verified that Load User Profile was set to true for my Application Pool and then set setProfileEnvironment to true in applicationHost.config. I did the last part by editing applicationHost.config located at:
C:\Windows\System32\inetsrv\config\applicationHost.config

Accessing Database with windows service

I was implemented a windows application which is working perfectly.
The concept is to read an Access Database and export to MS SQL Server 2005 Database.
Now i want to make it as windows service and half way done. The problem is it is not working (Not updating the database).
The service was installed perfectly and running but not updating the database. I made that service as "Local Service", "Network Service", "Local System" and "User" bu not working for any of this type.
Can any one help me out for solving this.
The development environment is MS Visual Studio 2005, C#.NET, MS Access, MSSQL SERVER 2005 and Network supported Environment.
Thanks.
You could do this with Linked Server or an SSIS job running on SQL Agent which may well have been easier but... to tackle your question itself:
You mention trying different accounts to run the service - have you granted any of those accounts the appropriate rights on your target database to allow the service to update the data. Do they also have rights on your source (Access) database to read it.
Have you checked the Event Logs on the server and the SQL Server logs to look for reported errors, failed logins etc?
You could hook up the debugger to your running service to try and identify the problem whilst it's running or alternatively you need to write in some kind logging statements so that you can identify where your code is getting up to before it fails and log out the error message(s) so give you something to work with.

Running into an SQL Error with an MVC Application deployed on IIS

So I am new to working on web projects in general. I am working on an MVC application in Visual Studio 2008. I have generated an SQL database within VS, and I have deployed my application on IIS. However when I try to do anything in the application which will spark an SQL query, I get the following error:
"Failed to generate a user instance of SQL Server due to failure in retrieving the user's local application data path. Please make sure the user has a local user profile on the computer. The connection will be closed."
I have hit google on this problem, and people have suggested a number of solutions but I am unsure how many of them are relevant to me doing this when I'm doing this in VS2008,. I have tried a few simple things suggested like setting the trust level to full, and setting the Load User Profile to true in IIS, but no luck yet.
What edition of SQL are you running where you deployed the application to? If it is not SQL Express, you will need to remove "User Instance=True" from the connection string.

Portforward SQL Server?

I haven't done SQL in a while, so I need to freshen up on things. I have a SQL Database running on my computer, and my server is localhost. I made an app in VB.Net that connects to this database. Everything works fine and all, until I distrubute my app to another person. When they try to connnect it doesn't seem to work for them. Do you know whats happening, I copy the whole release folder to them, and they can't connect? Also does anyone know why my icon is not appearing for my application as well, when I give it to another person?
Sincerely,
Kevin
It looks like you are distributing the code with a connection to a MySQL server in localhost, but the other users do not have a SQL server installed. So, depending on what you actually want to do, you have alternatives:
You want to distribute your app with a database, where each user will have his own data (their own 'SQL server'): In this case I recommend you to use SQLite. That way, they don't have to install any database server because SQLite is a file-based DB server, all the funcionality is in the library, no install needed. http://sqlite.phxsoftware.com/ is a .NET binding that works very well.
You want for other people to connect to your database: Then you have to configure connectivity from your users to your database and have a means to configure the connection string, because you probably have "localhost" hard coded there now. Opening the DB server to the world is not a very wise thing to do in general, YMMV. A good alternative is to offer a web services / REST interface for clients to access the data instead of opening direct connections to the DB server.