I have tried to delete a SQL database from the azure portal. It looks like it has failed part way though. The database doesn't show up under the list of SQL servers in the Azure portal. However if I login to the server through SSMS it is still there. I now can't delete the database or create a new one with that name.
I've tried deleting the database with a query and get an error saying the database doesn't exits. If I try to create it either from the Azure portal or SSMS it gets an error saying it already exists.
I had a similar problem once, with SSL settings, where it would return that it is linked to the app even tho it wasn't, hence I was not able to delete it. After a couple of weeks of back and forward with the support, we removed it through azure resource explorer.
How to:
Once you are logged in, set read/write
In serach box find your resource
Click actions (POST/DELETE) // these should be available now since you have set read/write
Click Delete
Hopefully, this would help anyone who has any corrupted resources in Azure.
Related
so, I have to make an Application Page with Oracle Apex. It is relatively simple, I only need one table. I tried to connect to it by SQL, but here comes the problem. There is no DB-Link existing.
How do I create a database link. I have Admin rights for Apex and have access to the admin account on the database server, from which I would need the data. Previously the data would be sended by E-Mail to us.
The sending Mailadress is adminname#servername.domain.net, that way I know on which server the database is located
I sadly do not know how the Mail Protocoll works, cause this was created before I started there.
I also do not know where on the server the database is located, all I know is that it is somewhere on the server.
Kind regards
Elias
Over the weekend my Dev server experienced a very interesting issue. I have a scripts that periodically take several databases offline, and then bring them back online again. They ran, and took all the specified databases offline, but then failed to bring them online again, the specified error message was:
Msg 5011, Level 14, State 7, Line 4 User does not have permission to
alter database 'XXX', the database does not exist, or the database is
not in a state that allows access checks. Msg 5069, Level 16, State 1,
Line 4 ALTER DATABASE statement failed.
This doesn't seem right to me as they we're run from a user account that has the following properties set:
I further validated that it wasn't a permissions issue by logging on to that server, running SSMS as an Administrator and logging in with my windows credentials (also a admin account) and executing the following SQL on the offline database:
USE [master]
GO
ALTER DATABASE [XXX] SET ONLINE
GO
With the same results...
I've looked at the SQL logs for more details about the specific error, however there are no entries associated with this issue. I can reproduce this issue on every database on this particular server. The only way I've been able to get the databases online is by de-attaching and reattaching them.
Most other stack overflow tickets involving this error message are specific to one database or a specific user account. My issue spans all databases and all admin users I've tried so far, also my issue occurred on a script that had previous worked fine on this server and account, clearly something has shifted over the weekend that is causing this query to now fail. I wonder if anyone else has experienced this issue before?
Update 1
This post talks about how file security can trigger this error message, I granted full access to the user group on one of the databases, then reran the online command, no luck. My SQL Server service is running under a service account that is part of the "Administrator" user group and has full access to all database files.
Update 2
All sorts of interesting idea's put forward here, also discussed here. Lots of commands and ideas on how to repair damaged databases with a several combinations of repair like SQL command, unfortunately none of them work in my situation, they either won't run on offline databases, or after detach and reattachment do not report any errors. Of course, there are always a number of posts simply insisting that the solution is permission based and that running: GRANT ALTER ON DATABASE will resolve all issues. For my admin user account it shouldn't make a difference, but it's a moot point as I can't even run that command on a offline database...
Finally tracked down the issue, apparently we had a completely unrelated SQL database instance on the same server in recovery mode. While it was recovering we we're unable to bring any offline instances online. Detach/re-attach would work, and we could restore the database just fine, but just not set it online.
The separate database finished recovering and we are now able to run the command without issue. I suppose in the future, if I don't care about the database that's in recovery(which I often don't) I'll following the linked steps to get rid of it, before restarting SQL Server and proceeding:
Stop SQL Server
Delete MDF + LDF
Start SQL Server
Restore (may need to drop first, comes up suspect)
I have Azure and I just upgraded to the Pay-as-you-go option as I though being on the trial might be causing my issue, but it persists.
I try to make a database in SSMS and I get this error saying I don't have the right subscription:
The reason I want to do it from SSMS is because when I try to add the database through the azure portal it doesn't show up in the sys.database table:
One of my databases is dependent on another and can't find it when trying to add a stored procedure because it doesn't seem to be registering correctly with master.
What is going on and how do I fix it?
I figured it out. When making a new database you need to go to options and change service level to basic.
I have been experiencing random connection/handshake problems w/ a hyper server VM running SQL and SSRS
So the network guys suggested building a new VM and trying it there. (Have you tried rebooting? )
I asked that they rename the old server (--> SQLBKUP) and name the new server to the current name (--> SQL) so all my connection strings will continue to work.
Regardless the wisdom of that approach, that is all now done.
All of our applications work. (and the weird handshake issue is gone,joy)
I have reinstalled SSRS and I thought I was home free.
We backed up and restored the ReportServer and ReportServerTemp databases to the new server.
If i try to point to these databases , I keep getting this error
The report server installation is not initialized. (rsReportServerNotActivated) Get Online Help
Any all information I can find about this for 2012 says that the initialization happens automatically when you configure a database.
I tried creating a new database, and presto, everything works fine.
I reconfigured SSRS to point at the old database and I again get the rsReportServerNotActivated error.
I also 'powered down' SQLBKUP in case it was causing some confusion, I cant imagine what that might be, but why not... This did NOT correct the problem.
Any ideas on why the databases that were working on 1 server wont work on the new one?
Searching the interweb for this issue I find two results for 2012 SSRS (many hits for 2005 issues/resolutions )
this article details how the RSExec role should be configured, I have verified that is all correct.
https://msdn.microsoft.com/en-us/library/cc281308.aspx
this article details the mechanics of various ways to move a database. The back up and restore operations went off w/o a hitch.
https://msdn.microsoft.com/en-us/library/ms156421.aspx
neither article mentions cleaning up any server names, ip addresses, etc. that might be in a config table. Inspecting the tables in SSMS, I dont see any tables that look like they might need such attention.
I can always recreate the environment, I am aout to that point, at least I will know what I have in front of me. If anyone has any suggestions, i would appreciate it, Im sure I will be up for a while... :-)
tyia
greg
You are getting that error because you haven't moved the old encryption keys to the new server. SSRS uses encryption to secure credentials and connection information. You'll need to get the encryption keys from the old server and restore them to the new one OR if you don't have the keys anymore you can create new ones but you'll need to setup your connection information again.
First backup your old encryption keys:
Start the Reporting Services Configuration Manager, and
then connect to the report server instance you want to configure.
Click Encryption Keys, and then click Back Up.
Type a strong password.
Specify a file to contain the stored key. Reporting Services appends a
.snk file extension to the file. Consider storing the file on a disk
separate from the report server.
Click OK.
Then restore the keys to the new server:
Start the Reporting Services Configuration Manager, and then connect to the report server instance you want to configure.
On the Encryption Keys page, click Restore.
Select the .snk file that contains the back up copy.
Type the password that unlocks the file.
Click OK.
You can also use the rskeymgmt utility, see the MSDN article: Back Up and Restore Reporting Services Encryption Keys.
If you don't have access to the older server you'll need to delete and recreate the encryption keys. Once you delete the keys the server will automatically re-initialize itself and you'll need to re-enter all of the lost encrypted information.
The following things will occur when you delete the encryption keys:
Connection strings in shared data sources are deleted. Users who run reports get the error "The ConnectionString property has not
been initialized." Stored credentials are deleted. Reports and
shared data sources are reconfigured to use prompted credentials.
Reports that are based on models (and require shared data sources configured with stored or no credentials) will not run.
Subscriptions are deactivated.
Steps to delete the keys:
Start the Reporting Services Configuration tool, and then connect to
the report server instance you want to configure.
Click Encryption Keys, and then click Delete. Click OK.
Restart the Report Server Windows service. For a scale-out
deployment, do this on all report server instances.
This is from MSDN - Delete and Re-create Encryption Keys. The article has a lot more useful information.
For more information also read Configure and Manage Encryption Keys
I have created a cloud database and was able to connect successfully thru SSMS.
Now I want to create a table in that.
Henceforth after the successful connection ( in am doing thru SSMS) when I am trying to connect to the database i.e. MyFirstCloudDB database which is available in the Available Databases section of SSMS, I am getting the error message " The database MyFirstCloudDB" is not accessible.
What to do now?
EDIT:
I have success accomplished my work.
But what I have done is that after I logged in to my SQL AZURE platform thru SSMs, first I created a database(say myFirstDB).
Then I logged out. Again I connected and this time Under Options->Connect to Database->I typed myFirstDB and then connected.
After that I created a table and inserted some values.
I have included this paras by thinking that if someone like me face the same problem then they can go ahead with this solution.
Thanks for the great support of Mr. Rob Farley for being with me in this journey and also to all the SO members. This forum is really really great (:
Pls help.
You need to login to your new db as your admin login and create a user for your new login. Then try connecting as the new login again.