I stopped SQL Server (MSSQLSEVER) and SQL Server Agent services and deleted the backup file and data file was located at C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL. Log file is still there:
Now I can't connect to SQL Server
Can not start SQL Server (MSSQLSERVER) and SQL Server Agent services as well
Could you suggest me a solution to connect to my SQL Server instance?
Image of the error message:
I really do not have enough information to diagnose this issue.
However, I have two ideas of what you did.
1 - What you showed me in the picture is the data and log directories. They contain all the system databases by default. See image below.
If you have not done a shift delete of the files and directory, stop the sql server instance and recover them from the recycle bin and restart the sql server instance.
Be VERY careful when deleting directories.
If you do not have these files handy, you might have to re-install SQL Server.
2 - If you data files are in another directory, which I doubt. Then, look in the windows event log and/or sql error log for errors. Please post more details.
J
You're not going to be able to connect to the SQL until the agent service is running again.
I think I need more information about what happens when you try to start the service. Also, I'd probably (if possible) try to restart the machine. Though that probably shouldn't be necessary, dependent on OS you're running it might help.
If you could post what happens when you try to start the service, that might be helpful.
Is the SQL service running? The agent service is not required for connecting to an instance. To regain access to SQL server after deleting required files, read the following msdn article: https://msdn.microsoft.com/en-us/library/dd207004(v=sql.120).aspx
I have the following problem. I have a SSIS Package that works fine when I execute it from visual studio, but when I execute it through the SQL Server Agent it gives me this error (I have it in spanish so I'll translate it and it might be a bit different from the normal message):
"Can't find connection "{(the id of one of my database connections)}". The Connections collection returns this error when it can't find the specific connection element.".
The SQLSERVERAGENT user has privilegies in the project's folder.
When planning the execution, I used the package file as a origin, if that has something to do.
I ran out of ideas and don't know what to do. Any help would be greatly appreciated.
Thanks in advance,
Khor
I finally made it work.
The problem was that the user who created the packages had permissions on the server I was accessing with the ODBC to but the SQLSERVERAGENT user didn't.
I changed the user in the SQL Server Agent service from SQLSERVERAGENT to the user who created the packages to make sure that this was the problem and it worked fine, so the solution is either leave the service with this user or give permission on the other server to the SQLSERVERAGENT user.
I have a SQL Server 2012 database with filestream enabled. However, when I backup it and try to restore it on another SQL Server 2012 instance (on another machine), I simply get this message that:
No backupset selected to be restored.
Not even a single line of more explanation. What's wrong here?
Every other database without filestream is OK and can be restored successfully. Is it something related to filestream? Should I install a hotfix or something like that.
I had this problem and it turned out I was trying to restore to the wrong version of SQL. If you want more information on what's going on, try restoring the database using the following SQL:
RESTORE DATABASE <YourDatabase>
FROM DISK='<the path to your backup file>\<YourDatabase>.bak'
That should give you the error message that you need to debug this.
My problem ended up being permissions. I'm on a dev machine and copied via Homegroup. Somehow, probably based on where I copied the file to, the permissions got messed up and Management Studio couldn't read the file. Since this is dev I just gave Everyone permissions to the bak file and could then successfully restore via the GUI.
When running:
RESTORE DATABASE <YourDatabase>
FROM DISK='<the path to your backup file>\<YourDatabase>.bak'
It gave me the following error:
The media family on device 'C:\NorthwindDB.bak' is incorrectly formed. SQL Server cannot process this media family. RESTORE HEADERONLY is terminating abnormally. (Microsoft SQL Server, Error: 3241)
Blockquote
Turns out You cannot take a DB from a Higher SQL version to a lower one, even if the compatibility level is the same on both source and destination DB.
To check the SQL version run:
Select ##Version
To see the difference, just create a DB on your source SQL server and try to do a restore from your backup file, when you do this whit SSMS, once you pick the backup file it will show some info about it as opossed to when you open it from a lower version server that will just say "no backupset selected to be restored"
So if You still need to move your data to a lower version SQL then check This.
Run SQL Server Management Studio as an administrator (right-click the shortcut/exe, then select "Run as Administrator"), then try to restore.
I thought I was not stupid enough to mix up the versions - however, I didn't realize that on my new server, a SQL Server 2005 instance was already installed from birth named SQLEXPRESS. When trying to restore my SQL Server 2008 R2 backed up database in SSMS 2012 to the SQLEXPRESS instance, the list of backup sets was empty.
Eventually I realized that the SQLEXPRESS instance on the server was not a 2012 instance, but a 2005. I disconnected and connected to the actual 2012 instance (in my case named SQLEXPRESS2012), and it (obviously) worked.
My problem was that my user was in the Builtin-Administrators group and no user with Sysadmin-role on SQL Server.
I just started the Management Studio as Administrator. This way it was possible to restore the database.
FYI: I found that when restoring, I needed to use the same (SQL User) credentials to login to SSMS. I had first tried the restore using a Windows Authentication account.
In my case, it was permissions and the fact that I used "Restore Files and Filegroups..." rather than simply "Restore Database ...".
That made the difference.
For me it's a user privilege issue.
I logged-in with sa user and its working fine.
For me the problem was having the .BAK file located in an encrypted folder on the server. Even with full Admin rights, I could never get SSMS to read the file. Moving the .BAK to an unencrypted folder solved my problem. Note that after moving the file you may have to also change the properties on the actual file to remove encryption (right click, properties, advanced, uncheck "encrypt contents to secure data".
In my case (new sql server install, newly created user) my user simply didn't have the necessary permission. I logged to the Management Studio as sa, then went to Security/Logins, right-click my username, Properties, then in the Server Roles section I checked sysadmin.
I had the same issue with SQL Server 2014 (Management Studio could not see the folder in which the backup file resided, when attempting to locate it for a Restore operation). This thread held the answer that solved my problem. Quote:
The SQL Server service account can be found by Start->Control
Panel->Administrative Tools->Services. Double-click on the SQL Server
service->Log On tab. You'll either be using the "Local System account"
or "This account" to define a specific account. If you are using the
Local System account, you won't be able to reference backups that are
not local to the server. If, instead, you have defined the account to
use, this is the account that needs to have access to the backup file
location. Your ability to access the backups using your personal logon
is irrelevant; it is the SQL Server account that is used, even though
you are initiating the backup. Your IT people should be able to
determine what rights are granted to each account.
Hope that helps someone.
For me, it was because the backup file was still open by another process. Here's the event log:
BackupDiskFile::OpenMedia: Backup device 'X:\Backups\MyDatabase\MyDatabase_backup_2014_08_22_132234_8270986.bak' failed to open. Operating system error 32(The process cannot access the file because it is being used by another process.).
Simply closing and reopening Sql Server Management Studio resolved it (so obviously it was ssms.exe that had the handle..)
In my case, it was a permissions issue.
For the Windows user, I was using did not have dbcreator role.
So I followed the below steps
Connect as sa to the SQL server
Expand Security in Object Explorer
Expand Logins
Right click on the Windows user in question
Click on Properties
Select Server Roles from Select a page options
Check dbcreator role for the user
Click OK
Another potential reason for this glitch appears to be Google Drive. Google Drive is compressing bak files or something, so if you want to transfer a database backup via Google Drive, it appears you must zip it first.
If you want to replace the existing database completely use the WITH REPLACE option:
RESTORE DATABASE <YourDatabase>
FROM DISK='<the path to your backup file>\<YourDatabase>.bak'
WITH REPLACE
Using SQL Server 2012 Express.
My error (from the SQL Manager - Restore Database Dialog):
No backupset selected to be restored
Further, there were no backupsets shown in the list to select.
The issue was that I had moved 1 of the 5 backup files to a folder where the SQL Server service logon user did not have permissions - I tried to add that user, but could not get the NT Service\MSSQL$SQLEXPRESS user into the security list.
I moved the file under the Documents folder for the service user, and that enabled it to read all the files I had selected - 4 at that point - and the error changed to "media set missing" - then I looked around for another backup file, and when I added that I was able to restore.
The answers in this question helped me look in the right places and work my way to a solution.
For me, It was a permission issue. I installed SQL server using a local user account and before joining my companies domain. Later on , I tried to restore a database using my domain account which doesn't have the permissions needed to restore SQL server databases. You need to fix the permission for your domain account and give it system admin permission on the SQL server instance you have.
I got the same error message even though I backup and restore on the same single machine.
The issue was from here: when backup, i had 2 item in the destination box.
So the fix would be: make sure only 1 item in the 'destination' box. Remove all the others if there are.
I have run into the same issue. Run SSMS as administrator then right click and do database restore. Should work.
I think I get the award for the most bone headed reason to get this error. In the Restore Database dialog, the database dropdown under Source is gray and I thought it was disabled. I skipped down to the database dropdown under Destination thinking it was the source and made a selection. Doing this will cause this error message to be displayed.
I setup the my WCF service on server machine.
The server OS is Windows 2008 with SQL Server 2008 Express.
I am trying to access to my SQL Server (mdf) file to read data using LINQ to SQL.
I see that the DataContext is OK - but when I try to get information that in one of the table I get an exception
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 don't know what i need to define or change in the IIS 7.5 that I'm using in the server side.
Thanks for any help.
Update: the connection to the database file is fine - but getting information from table is thru an exception. The connection string is:
Data Source=.;AttachDbFilename=|DataDirectory|\ServiceData.mdf;
Integrated Security=SSPI;User Instance=True
If you already have a server, why don't you just attach the MDF to the SQL Server (Express) running, and then use it like a normal database on your server?
After you do this, use a connection string like:
server=Server\SQLExpress;Database=YourDatabaseName;Integrated Security=SSPI
I never quite liked the AttachDbFileName= and User Instance approach - seems like a (unreliable) hack to me, which really doesn't make sense if you're running on a server machine.
The reason that you are getting this error message is because your code is in the security context of a user that has never logged on to the server. The user therefore does not have a profile and you therefore get an error when the code attempts to write to a non-existant profile.
You could use marc_s's approach or you could run as a user that has a profile.
I have an SSIS package that queries a view for some records then sends off an email using Database mail. I want to deploy the package to the SQL Server that these views exist in and then schedule us using SQL Server Agent but i've run into a number of issues.
The main problem is that within the job there is a connection manager that has stored credentials for a SQL Server account that has access to the views and email profile. I've set the package to EncryptSensitiveWithPassword instead of User Key but i can't seem to find any way to actually pass that password the the SQL Server Agent when the job is run. So when it executes it fails since it can't connect.
A bunch of websites say to use the config file, but when I go that route it breaks the job entirely complaining that the OLEDB connection can't be established. In that scenario I can't even run the job on my machine locally.
A few other sites recommended copying the package to the local ssis package store on the machine, but I only have access to the machine through SQL Server Tools, I can't remote in or install anything on the file system so I have to install through the manifest file using the SSIS deployment process.
I've read something about storing settings in another DB table, but that again presents issues with permissions on the server.
Finally I tried passing /password or /decrypt in the job scheduler, but when i click ok it scheduler removes that parameter.
This is an internal server and security isnt really a big concern, Any idea how i can pass the decryption password in plaintext or just tell SSIS to not bother securing sensitive data?
The trick is:
When saving the package in SQL Server Business Intelligence Studio, ensure the Package Properties > ProtectionLevel is set to EncryptSensitiveWithUserKey.
When you import the SSIS package into the SQL Server (from SQL Mgmt Studio > object explorer > [server] Integration Services > Stored Packages > MSDB > right-click > Import Package > set Package location to File System, Select the file in Package path, and select the option "Rely on server storage and roles for access control". I would guess when importing the .dtsx file you have to be logged in as the same user that saved the .dtsx file.
This means that the password is saved with the package and therefore can be used when anyone executes the package. If it's something you don't want anyone to execute you then lock down security appropriately.
Alternatively you could change the Connection so it uses Integrated Security (windows authentication instead of a sql login) and change the Job so it executes the package as a user that has access to the database & view that's queried by the package. This is the preferred option from the view that you don't need passwords anywhere and instead manage it via user identity and permissions.
It sounds like when you're using the config file that you're not setting up the config file correctly.
What is the exact error that you're receiving when running it locally? I can try to recreate the issue.
do you have the package set up in bids to store the passwords, and then save the package to ssis and tell it to encrypt the passwords? if you're not saving them locally, it could be that you've lost your passwords and then pushed the package without them.