I understand that there are a few threads existing on this area, around a local server using Azure MSSQL as a linked DB.
My specific issue is the linked server appears, connects and I can view the databases but when trying to go deeper, as in see the tables I get the following error:
Reference to the database and/or server name in
'databasetable.sys.sp_tables_rowset2' is not supported in this version
of SQL Server. (Microsoft SQL Error, Error 40515).
I have tried any of the suggestions already mentioned via the other threads, and to no avail can I get any deeper than listing the databases on the Azure server from my local installation of SQL Server.
I experience the same issue when trying to do anything more than simple Select/Insert/update/delete/create Table/Drop table on my SQL Azure databases. It appears you cant do anything that touches the settings of SQL Server or any stored procs that touch system tables, perhaps because the SQL servers could be shared between multiple customers.
There are also documented areas where Azure SQL has limitations versus a local SQL Server.
We now have this capability using elastic database query, you need to follow two simple steps mentioned as:
Step-1: Create reference to external database
Step-2: Then create remote table reference in the target database
then you can execute remote queries just the way you do it with SQL Server.
Please refer for step by step details https://azure.microsoft.com/en-us/documentation/articles/sql-database-elastic-query-getting-started-vertical/
Related
I'm in the process of testing/playing about with Azure. We have moved an on-premise SQL Server database to an Azure Managed Instance, however, this contained a linked server to a Progress database via an ODBC DSN connection.
Of course this no longer works. Does anyone know if this is possible or will I have to import the various Progress tables into Azure via a different way?
Thanks.
You can't install drivers on a Managed Instance, so it only supports linked servers that use the SQL Server drivers.
As a workaround you can "double-hop" through a Linked Server on a small Azure VM running Windows and SQL Server Express Edition. See eg [Using Heterogeneous Linked Servers from Azure SQL MI][1]
Which is enough of a pain that you'd want to load the data into MI using some external tool, like SSIS or Azure Data Factory.
[1]: https://techcommunity.microsoft.com/t5/modernization-best-practices-and/using-heterogeneous-linked-servers-from-azure-sql-mi/ba-p/3074530
Does the change of the host name of the server impact the functioning of Microsoft SQL Server?
Yes, there are some additional steps that you need to perform after changing the host name.
I could not find the relevant documentation for SQL Server 2012 online any more, but here is the official document for SQL Server 2016-2019:
Rename a Computer that Hosts a Stand-Alone Instance of SQL Server
In a nutshell, you need to execute
sp_dropserver <old_name\instancename>;
GO
sp_addserver <new_name\instancename>, local;
GO
to update system metadata and then restart SQL Server.
Additional steps (see the linked document above) might be necessary if you use:
a failover cluster,
replication,
Reporting Services,
database mirroring,
Windows groups containing a hard-coded reference to the computer name,
remote logins,
linked server configurations or
named pipes.
Obviously, the connection strings of any clients connecting to your server will need to be updated as well.
I am migrating on premises SQL server database to Azure PaaS SQL database using Data Migration Tool. I am not using Data Migration Service Instance mechanism to migrate the database as it would require VPN on the corporate network and I do not see any benefit doing that way in my case.
There is one error which I am stuck on and a bit confused. When migrating a stored procedure which use automation stored procedures, I get the following error:
When I run Alter procedure script directly on Azure SQL database , I get this error;
Reference to database and/or server name in 'MASTER..sp_OACreate' is not supported in this version of SQL Server.A few answers to similar question on stackoverflow suggest that Azure SQL does not support automation stored procedures but the Microsoft link has a green tick against Azure SQL which suggest it does; https://learn.microsoft.com/en-us/sql/relational-databases/stored-procedures/ole-automation-sample-script?view=sql-server-2017.
A snippet of the sp is:
Is it true that automation stored procedures are not supported in Azure SQL and if thats hte case then what is hte workaround apart from rewriting the sp?
SQL Azure prevents you from calling server resources. sp_OACreate attempts to create a reference to an OLE object on the server; that's simply not allowed on Azure SQL Database. So you will need to redesign your solution to move this type of logic in a middle-tier of some kind, such as a Web Role in Windows Azure.
The question: Is it possible to point a view in database A running on Azure SQL Database service to tables/views on a SQL server running in a VM? I've tried external tables but come up short.
Scenario:
Two applications that is exchanging data, from two different vendors.
We've got three databases in total. One for each application and an integration database with views that both applications use either directly or through views.
The issue now is that we want to migrate to Azure and would prefer to use the Azure SQL Database service as much as possible, but one of the applications is not ready for it and therefor it's database has to be hosted on either a managed instance or in a VM.
The issue now is that there's view's in database A (running on Azure SQL Database service) that points to views and tables in the integration database, which again references tables in database B (running on SQL Server on the VM).
The short answer is "no". You can use external tables to query other SQL Azure databases, but there is no exact analogue for linked servers in Azure SQL Database. You can use SQL Azure Managed Instance (which supports SQL-SQL linked servers but not arbitrary linked servers).
There is a workaround, however. You can run SQL Server in an Azure VM and have it point to SQL Azure as a target as well as the other sources you want to connect. Then you can push data to/from Azure SQL DB using the SQL Server in a VM. You don't have the same management overhead in this approach since you don't really need to host data in the SQL Server if you don't want to do so. Note that this will be slower than doing direct connections to SQL Azure, but you can try to do this for a period of time if it would help you during a migration.
in my development environment we support the application both on MSSQL Server as well as Oracle. The database schema of both of these RDBMS are same.
while development we found that the developer made a mistake and forgot to change the oracle database for the last 1 yr. therfore the oracle script is quite behind in term of schema from SQL Server schema script.
now the question is how i can compare the two RDBMS systems to find the difference and make the oracle script updated
If there are no track log from which it's possible to find and reproduce all changes applied to SQL Server since first detected inconsistency with Oracle version, or that changes was applied, but only partially, you really need to compare objects presented in both databases.
In this case setup a link between databases on any side and use system dictionary views to compare table structures and other objects to find differences and, possible, to generate script for Oracle scheme rollup.
If you want to act from MS SQL Server side:
Install and configure Oracle Instant Client
Install Oracle ODAC
Follow Microsoft recomendations (64-bit version)
Connect as any user with dba role (or use same Oracle schema where object resides) to Oracle from MS SQL database
If you want to act from Oracle Server side:
Install and configure Oracle Database Gateway for SQL Server.
Create database link to MS SQL Server.
After successful configuration you may join Information schema views on SQL Server side with Data dictionary views on Oracle side to find differences.
Of course there are many troubles at this way like different data types, but it gives a chance to automate at least part of work.