I have a virtual machine in the cloud that runs SQL Server and a database that is publishing for merge replication. I have followed all the steps as outlined in Microsoft documentation but my subscriber client is getting stuck with the following error...
The remote server 'xxxx.cloudapp.net' does not exist, or has not been designated as a valid Publisher, or you may not have permission to see available Publishers.
The client has created the subscription and is able to connect to the server in order to get this far and so the server definitely does exist and can be communicated with. I have given full permission to access the ReplData directory for all users so I cannot see how permission would be a problem.
Any ideas?
Related
I am trying to restored a .bak file on an Azure SQL server through SSMS.
The reason why I am doing this is that my company unfortunately blocked any action on the Azure portal itself and therefore I have to find another way around.
I am able to connect successfully to the DB on Azure with my admin account through SSMS.
I first successfully restored the .bak on my local database. And then I am trying:
Again, I am able to connect through the same SSMS to the SQL db.
Moreover, when starting this procedure I get asked to connect first to the DB, which works successfully! What I mean is:
It doesn't give me any error, which is weird because if I try to connect with a wrong password it tells me right away that is wrong. So it kind of accepts it. It's only after when I really start the deployment that it gives me the problem:
Just for now, Azure SQL database doesn't support restore from .bak file.
You work flow should be right, restore the .bak file(database) into a local SQL Server firstly, then deploy the restored database to Azure with "Deploy database to Microsoft Azure SQL database".
Make sure you are using the server admin account of the Azure SQL database. Per my experience, the error is usually caused by the permission limits.
If all of these(SSMS) don't work, please thy other ways. Please try Data Migration Assistant(DMA) migrate the database. If DMA still give the same error, we can ensure that it's not caused by the tools, you need another higher Azure SQL database account permission.
HTH.
Working solution was to use the export data task:
For some reason this worked and the publish to ASQL task from SSMS didn't. I understand this is very based on the restrictions imposed by my company but at least this solution worked.
NOTE: as both Source and Destination use SQL Server Native Client .
Moreover when setting the Destination the refresh of the list of databases might not work (depending on your permissions on Server level) but if you type directly the name of the database it will work. Talking about this:
I have a SQL database created and I am trying to deploy/move that database to the Azure Cloud by using the Deploy Database to SQL Azure Wizard in SQL Server Management Studio. But I have ran into an error after trying to deploy it. I am using the SQL Authentication to log in with my credentials. I also tried installing the Data Migration Application.
The error is:
TITLE: Microsoft SQL Server Management Studio
One or more unsupported elements were found in the schema used as part of a data package.
Error SQL71624: The permission 'CONNECT' is not valid for the target object 'guest' in Microsoft Azure SQL Database v12.
(Microsoft.SqlServer.Dac)
BUTTONS:
OK
I don't understand what this error means and also I don't understand why this error is happening. I looked on the internet for possible solutions but could not find any information. Please help me.
SQL Azure and regular SQL Server aren't entirely compatible.
One of the things that is enabled on regular SQL Server is the guest login. This login allows connection to instance, with a default database of master. Once connected, the user can switch to a different database (use [thedatabase]) if they have the authority to do so.
But in SQL Azure, you connect directly to a single database, and can't switch databases on the connection. So the guest account has no function.
On your source instance (the one you want to migrate), you can revoke this ability so that the wizard won't try to migrate it. Execute revoke connect from guest on your on premise instance.
I'm trying to connect from my azure SQL DB to link to the local SQL DB and create some linked tables that i can run some reports on within the Azure environment.
I've tested that i can follow the steps and successfully connect to another SQL Db within my Azure environment and this is working fine, so the steps i am following are correct.
However when i try to run the same steps connecting against my local DB i receive the following error:
A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - The certificate chain was issued by an authority that is not trusted.)
Steps i'm following are
Create Database scoped creds (using my same details that can log on via Management Studio)
create external data source
Create external table using the details created above.
This creates a external table within my azure database but when i try to select from this table i get the following message
A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - The certificate chain was issued by an authority that is not trusted.)
So two questions really as i've googled for some time and a lot of the posts I've found seemed to be old.
Does Azure support connecting to a local DB?
And if so any ideas what this message means?
I've read up about this and the only comments i could see mentioned TrustServerCertificate=True to false. However i'm not sure where this is set and where the change is required? to me this looks more like a change within a connectionstring for coding rather than a db to db?
Elastic queries allow a query to span multiple Azure SQL Databases but on-premises SQL Server instances can not be part of elastic queries.
My suggestion is to perform replication of on-premises databases to Azure SQL Database or use SQL Data Sync so you can have an always updated copy of on-premises databases on Azure SQL Database and you can then query them as local tables or with elastic queries on Azure SQL Database.
We have a windows service that provisions Azure SQL databases for our clients. We are using Microsoft.WindowsAzure.Management.Sql API for this. Our service creates the SQL Server instance and deploys the schema using a DACPAC.
When running recently we received the following warning during the DACPAC deployment step:
Warning - Database 'AG61_xxxxx' on server 'xxxxxx.database.windows.net' is not currently available. Please retry the connection later. If the problem persists, contact customer support, and provide them the session tracing ID of '{xxxxxxxx-C7D7-4504-AF25-4C3AC020BE90}'. (73144)
The problem we have is that this database is now left in an inconsistent state:
It isn't listed in the Azure Portal under databases.
The Azure API doesn't return it in list of databases on the server.
Attempting to recreate the same database on the same server, either via code OR via the Azure Portal, returns
Database 'AG61_xxxxx' already exists. Choose a different database name.
However, I can log into SSMS as the admin user and see the database listed. If I try to delete it I receive the following error:
Failed to connect to server. (Microsoft.SqlServer.Smo)
Additional information:
Database 'AG61_xxxxx' on server 'xxxxxxxxxx' is not currently available. Please retry the connection later. If the problem persists, contact customer support, and provide them the session tracing ID of 'FBE26206-C3B6-4771-B0EF-4BCA9C154F28'. (Microsoft SQL Server, Error: 40613)
According to Microsoft, error 40613 is transiant and should only last a few seconds. We've been unable to do anything with this database for 3 days.
Has anyone else experienced this? I'd like to know if there is something we can do to recover the database on this server such that we don't have to have the client change their connection strings etc.
I'd also like to know if there is anything I could do in future to mitigate this happening again.
Can you point me to any information about cross-server access to the SQL Server FileTable share? We wanted to use this to manage variable-content for our Web Applications (which are running in a load-balanced configuration). The share works great when local on the SQL Server VM, but when trying to connect to it from a Web Server VM it doesn’t work, no matter what domain account I’m running under (even a domain account with SQL Server SysAdmin).
Note that we have connectivity to SQL Server, just not the FileTable file share. That connectivity is across the private subnet. Our private AD has DNS records only for the private network of the machines within the our private domain.
When running a command prompt on the VM hosting SQL Server and using a domain account that does NOT have any database permissions, we get the expected result (access denied) when trying to access the FileTable share: <image>
When running a command prompt on the VM hosting SQL Server and using a domain account that DOES HAVE database permissions, we also get the expected result (access) when trying to access the FileTable share: <image>
When running a command prompt on one of the Web Server VMs and using a domain account that DOES HAVE database permissions, we get an UNEXPECTED result (device is not ready) when trying to access the FileTable share: <image>
From the web server we can connect to the default share on any of the disks attached to the SQL Server VM: <image>
I’ve searched extensively and looked at many articles which describe setup and using SQL Server FileTables. None of these articles describe the problem I’m seeing.
Left to my own devices, my next step would be to configure FileTables in a non-Azure environment to see if results are similar. But that’s a lot of work that I don’t have time to do. As a work-around, I might use SSIS to mirror the SQL Server FileTable share across another share on the SQL Server VM so that the applications running on the Web servers can get access to the FileTable share indirectly.
Do you have any idea what it is that I might not be thinking of? How can we connect to the SQL Server FileTable share from another machine? Can you point me to any resource that might be able to help resolve this issue?