I'm having hard times with the SQL Error
Failed to generate a user instance of SQL Server due to a failure in starting the process for the user instance. The connection will be closed.
No matter what I do (yes, I have the SQL Express running in the Local account and deleted the SQLExpress folder on Local Profile), users under Windows 2008 always get this issue and sometimes on Vista as well (not that frequent).
I do need to find other ideas!
I was thinking move to SQLite (as there is a wonderful Provider) or even use XML file instead.
All I do is manage WebParts as panels that each user can modify their visibility and place. When done editing it saves automatically into the user instance.
I need only this functionality but I can't find a decent way to drop SQL Express 2005 User Instances ... any ideas?
Any help is highly appreciated, Thank you.
I worked for webhosting company where SQL Express was used for freehosting users. We never experienced this problem so it must be some weird combination of parameters.
I suggest to do some probing
Use Process Monitor to trace which files/directories/registry entries is SQL Express trying to access when the error occurs. Using this utility you can also locate problems with access rights.
Look into SQL Express log located in C:\Documents and Settings\user_name\Local Settings\Application Data\Microsoft\Microsoft SQL Server Data\SQLEXPRESS for some additional info
Make sure you have user instances enabled running this on SQL express default instance
sp_configure 'user instances enabled', '1'
Just for sure I would try to list all user instances and eventually try to connect to one.
To list user instances connect to default one (usually named COMPUTER\SQLEXPRESS) and run:
SELECT instance_pipe_name
FROM sys.dm_os_child_instances.
Then use value in instance_pipe_name with sqlcmd utility:
C:>sqlcmd -S np:\.\pipe\69651E0A-5550-46\tsql\query.
Now you are connected to user instance. Try to execute some DML.
You probably did this but for sure have a look in Windows Event Viewer
If nothing comes up from probing you can always create database using snandard way on SQL Express default instance (connect to server, create database, setup connection string and use it instead of database.mdf in your solution).
Using "microsoft sql server compact 3.5" gives you almost any of the normal sqlexpress functionality while being easily portable without a real server to be put on.
http://www.microsoft.com/Sqlserver/2005/en/us/compact.aspx
Unless you're doing a big and complex application (lots of stored procedures, triggers and such), its a nice way to work.
Here's some other information :
http://blogs.msdn.com/stevelasker/archive/2006/11/27/sql-server-compact-edition-under-asp-net-and-iis.aspx
Related
Apparently, using AttachDbFilename and user instance in your connection string is a bad way to connect to a DB. I'm using SQL server express on my local machine and it all seems to work fine. But what's the proper way to connect to SQL server then?
Thanks for your explanation.
Using User Instance means that SQL Server is creating a special copy of that database file for use by your program. If you have two different programs using that same connection string, they get two entirely different copies of the database. This leads to a lot of confusion, as people will test updating data with their program, then connect to a different copy of their database in Management Studio, and complain that their update isn't working. This sends them through a flawed series of wild goose chase steps trying to troubleshoot the wrong problem.
This article goes into more depth about how to use this feature, but heed the very first note: the User Instance feature has been deprecated. In SQL Server 2012, the preferred alternatives are (in this order, IMHO):
Create or attach your database to a real instance of SQL Server. Your connection string will then just need to specify the instance name, the database name, and credentials. There will be no mixup as Management Studio, Visual Studio and your program(s) will all be connecting to a single copy of the database.
Use a container for local development. Here's a great starter video by Anna Hoffman and Anthony Nocentino, and I have some other resources here, here, and here. If you're on an M1 Mac, you won't be able to use a full-blown SQL Server instance, but you can use Azure SQL Edge if you can get by with most SQL Server functionality (the omissions are enumerated here).
Use SqlLocalDb for local development. I believe I pointed you to this article yesterday: "Getting Started with SQL Server 2012 Express LocalDB."
Use SQL Server Compact. I like this option the least because the functionality and syntax is not the same - so it's not necessarily going to provide you with all the functionality you're ultimately going to want to deploy. Compact Edition is also deprecated, so there's that.
Of course if you are using a version < SQL Server 2012, SqlLocalDb is not an option - so you should be creating a real database and using that consistently. I only mention the Compact option for completeness - I think that can be almost as bad an idea as using AttachDbFileName.
EDIT: I've blogged about this here:
Bad Habits : Using AttachDBFileName
In case someone had the problem.
When attaching the database with a connection string containing AttachDBFile
with SQLEXPRESS, I noticed this connection was exclusive to the ASP.NET application that was using the database. The connection did block the access to all other processes on the file level when made with System.Data.SqlClient as provider.
In order to assure the connection to be shareable with other processes
instead use DataBase to specify the database name in your connection string
Example or connection string :
Data Source=.\SQLEXPRESS;DataBase=PlaCliGen;User ID=XXX;password=ZZZ; Connect Timeout=30
,where PlaCliGen is the name (or logical name) by which SQLEXPRESS server knows the database.
By connecting to the data base with AttachDBFile giving the path to the .mdf file
(namely : replacing DataBase = PlacliGen by AttachDBFile = c:\vs\placligen\app_data\placligen.mdf) the File was connected exclusively and no other process could connect to the database.
Apparently, using AttachDbFilename and user instance in your connection string is a bad way to connect to a DB. I'm using SQL server express on my local machine and it all seems to work fine. But what's the proper way to connect to SQL server then?
Thanks for your explanation.
Using User Instance means that SQL Server is creating a special copy of that database file for use by your program. If you have two different programs using that same connection string, they get two entirely different copies of the database. This leads to a lot of confusion, as people will test updating data with their program, then connect to a different copy of their database in Management Studio, and complain that their update isn't working. This sends them through a flawed series of wild goose chase steps trying to troubleshoot the wrong problem.
This article goes into more depth about how to use this feature, but heed the very first note: the User Instance feature has been deprecated. In SQL Server 2012, the preferred alternatives are (in this order, IMHO):
Create or attach your database to a real instance of SQL Server. Your connection string will then just need to specify the instance name, the database name, and credentials. There will be no mixup as Management Studio, Visual Studio and your program(s) will all be connecting to a single copy of the database.
Use a container for local development. Here's a great starter video by Anna Hoffman and Anthony Nocentino, and I have some other resources here, here, and here. If you're on an M1 Mac, you won't be able to use a full-blown SQL Server instance, but you can use Azure SQL Edge if you can get by with most SQL Server functionality (the omissions are enumerated here).
Use SqlLocalDb for local development. I believe I pointed you to this article yesterday: "Getting Started with SQL Server 2012 Express LocalDB."
Use SQL Server Compact. I like this option the least because the functionality and syntax is not the same - so it's not necessarily going to provide you with all the functionality you're ultimately going to want to deploy. Compact Edition is also deprecated, so there's that.
Of course if you are using a version < SQL Server 2012, SqlLocalDb is not an option - so you should be creating a real database and using that consistently. I only mention the Compact option for completeness - I think that can be almost as bad an idea as using AttachDbFileName.
EDIT: I've blogged about this here:
Bad Habits : Using AttachDBFileName
In case someone had the problem.
When attaching the database with a connection string containing AttachDBFile
with SQLEXPRESS, I noticed this connection was exclusive to the ASP.NET application that was using the database. The connection did block the access to all other processes on the file level when made with System.Data.SqlClient as provider.
In order to assure the connection to be shareable with other processes
instead use DataBase to specify the database name in your connection string
Example or connection string :
Data Source=.\SQLEXPRESS;DataBase=PlaCliGen;User ID=XXX;password=ZZZ; Connect Timeout=30
,where PlaCliGen is the name (or logical name) by which SQLEXPRESS server knows the database.
By connecting to the data base with AttachDBFile giving the path to the .mdf file
(namely : replacing DataBase = PlacliGen by AttachDBFile = c:\vs\placligen\app_data\placligen.mdf) the File was connected exclusively and no other process could connect to the database.
I have a windows form application (developed in VS Express 2013) that connects through an instance of SQL Server 2012 to a database. Both the application and database are on my local system; I just needed a GUI to more easily interface with this very large database that stores my research data. When I initially compile and deploy the application, it works fine and has no connection problems with the database. However, if I then attach the database in SQL Server Management Studio (which I sometimes want to do) I get an error the next time I try to use the application - "Cannot open database ..... requested by the login, the login failed". I get this error even if I take the database offline and detach it before quitting SSMS. And just to be clear - I'm not making any changes to the database in SSMS, I'm just looking at the data. The connection string used by VS is Data Source (LocalDB)\v11.0;AttachDbFilename=|DataDirectory|\CollectionMetricsDatabase.mdf;Integrated Security=True.
Any idea what the problem is?
Maybe the instance of SQL Server 2012 has a max number of concurrent connections and you exceed that with your two connections at once (SSMS connection and application's connection). Check the settings in SSMS.
Another thing to try - Based on your connection string, you are using Integrated Security, which in my experience means the application connects using Windows credentials. That can be fragile, because it means that whatever 'user' runs the application (if hosted in IIS, this will be the App Pool user) is the one whose Windows credentials are used. I would suggest creating a SQL login user (in SSMS) for the database, with db_owner access, and then changing the application's connection to be username/password based instead. You may need to enable Mixed Authentication for the SQL Server instance in SSMS if it doesn't already allow it.
You need to connect in SSMS with the localDB connection string. Attaching it will prevent it from working with localDB.
In SSMS, create a connection to (LocalDB)\v11.0. You should see your DB there already.
The problem is that you are connecting to the database file directly not through SQL Server.
Only one user can have a lock on the file at the time.
You need to recreate a connection string for your app.
That is why you were needing to detach the database.
Since this is only a personal project you could live with things as they are, at least you know the server is only running when you need it.
create connection msdn
I have to check if an SQL Server is installed on random computers (running code locally) and connect to the instance and find the version of the SQL Server. Is this possible without having logins?
I've been told not to use the registry to look for the information and instead been suggested a couple of methods that both require connection with the instance. This of course will require the SQL Server to be running.
For extra info, I need to run either ##version or SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')
I'd assume I need to at least use Windows Authentication, but will that be possible? These are computers that run in a production environment and I have "no control" over them (except that I can run my code on everyone of them).
If you want to ask the SQL Server instance a question you need to connect to it! And in order to do that you need a valid (Windows Authentication or SQL Server Authentication) connection-string - so someone needs to provider you with that!
Basically I have a windows form C# program that uses a SQL Server Express database to store data entered by the users. I want to add the ability for the user to be able to backup their database and then load a backup or another database into the programs database.
If someone could point me in the right direction like an article or tutorial that would be great, because I have hit a dead end.
Thanks
You have a few options to do this:
On the server directly call BACKUP DATABASE, RESTORE DATABASE commands.
Use SMO (SQL Server Management Objects) to perform the backup restore operations programatically. (Specifically this sample)
Use some third party utility/library.
You may want to look at using this suggestion:
http://codeasp.net/articles/sql-server/118/backup-your-database-using-an-sql-command-export-to-bak
The nice thing about SQL Server is that you can do more or less everything with SQL (T-SQL or some variation thereof) - this is nice because it means that it is relatively easy to do most things without having to worry about (for example) the availability of SMO and further in a reasonably generic fashion.
The second nice thing is that if you run a command in SQL Server Management Studio (a version of which can be downloaded for SQL Server Express) it will, more often than not (and certainly in the case of Backup and Restore), offer to let you save the the script to a file instead of executing it.
So, it would be straightforward for you to use SQL Server Management Studio to determine the structure of SQL based backu and resotre commands and from there to integrate those into your application.
There is, however, a "gotcha" - SQL server will only save backups to/restore backups from a drive that is visible to the machine & service account upon which the SQL Server instance is running, almost certainly not an issue if your application is running on the same machine as the user but potentially a problem if they are not.