Fist of all sorry for my bad English.
I am new for azure.We are planning to move some selected tables from our SQL database to azure SQL database because of it getting to much load.But existing stored procedure have joined with these tables in SQL server. So what is the best solution to get a result from both databases.
For example booking table right now in Azure database. But customer details, office details, courier details are in our existing SQL database.
Updated
Initially, we have only one database in sql server which contains all tables booking, customer details, office details, courier details etc. Due to heavy load, the client has decided to move some of the tables from sql server to Azure. So we have moved booking related tables into Azure. The issue is the database contains many stored procedures joined between all these tables. If I move some tables to Azure this won't work. I know there are methods to link multiple sql server to write stored procedures by adding those databases as 'Linked Servers' and access through [Server Name].[Database Name].[Table Name]. I think the same is possible between two Azure Sql databases.
My question is this cross-database querying is possible between two databases one is situated in SQL server and other is in Azure.
Thank you.
Azure supports cross database queries if both databases are in Azure ..In your case,it seems some of will be in OnPremises..
So the only option,which i can think of is to use is linked servers to azure..these queries can perform worse,depending on the data you want from them..
In General,you have to follow below steps to create Linked server to AZure..
1.Run odbcad32.exe to setup a system DSN using SQL Server Native Client.
2.Now create a linked server..
EXEC master.dbo.sp_addlinkedserver
#server = N’Can be any name′,
#srvproduct=N’Any’,
#provider=N’MSDASQL’,
#datasrc=N’name of DSN you created′
Now you can query azure from your local server like below
select * from [#datasrc name(dsn name)],db.schema.table
this blog explains step by step and goes into some details on what are the pitfalls
https://blogs.msdn.microsoft.com/sqlcat/2011/03/07/linked-servers-to-sql-azure/
Related
I'm very new to Azure so please don't judge me too harshly.
So, in this project, I've got SQL Server on-premises 'production' database which is the 'master' data. I'm writing a small .NET application that is published on Azure and it is using tables and stored procedures on Azure database. My idea is to have the data in the tables on Azure database up-to-date with the on-premises 'production' database tables.
I've created Sync Group and Sync Agent and it looks like data is flowing accurately from the on-premises Sql Server tables to Azure database tables.
The only problem I have is that when some records on 'prodution' are deleted these records will not be deleted from the Azure tables.
I guess the questions are: What am I missing in synchronization and is it even the right approach to update the Azure database tables using the 'Sync to other databases' tool?
Thanks in advance!
Make sure you have elected the Azure SQL Database as the Hub in your sync group and the on-premise as a member database.
For the Conflict Resolution Policy of the Sync Group, make sure you have selected "Member wins".
According your problem description, since your Azure SQL Data Sync group has be created, we can get that:
Your on-premise SQL server DB is member database.
The Azure SQL database is Hub database.
The Sync Direction of your Sync must be "Member to Hub" or "Bi-directional Sync",
The only problem I have is that when some records on 'production' are deleted these records will not be deleted from the Azure tables.
For your question, I don't think Conflict Resolution Policy can help you solve it.
There isn't a good solution now, I only can give two suggestions for you:
Set Automatic Sync: Off. Sync the data from on-premises SQL
server to Azure manually. This can help your keep
the data in Azure SQL DB for a long time.
Create a new table in Azure SQL database, don't add the new table to
sync group. Copy the data from your synced table to new table. Using the new
table for test.
Hope this helps.
I want to enter data from mutiple T-SQL queries into my azure sql database, We want to enter data in such a way so that we have 8 columns in a single table in azure sql database, and for those 8 columns we have multiple T-SQL statements that 1 for each that will enter the data from the select statments into the azure sql database, how can this be achieved, for long term we want this to run as a job going forward.
If your multiple T-SQL queries run in one database, I suggest you can think about the Azure Data Factory.
Azure Data Factory can help migrate data from one table or multiple tables to Azure SQL database by T-SQL queries.
You also can trigger the pipeline runs on a schedule. You can create a scheduler trigger to schedule the pipeline to run periodically (hourly, daily, and so on).
For details about Data factory, please see Azure Data Factory Documentation.
Tutorials:
Incrementally load data from multiple tables in SQL Server to an Azure SQL database
Copy multiple tables in bulk by using Azure Data Factory.
And if your source data is in SQL Server instance, you can create a linked server to Azure SQL Database, this also can help you achieve that.
You can query and insert data to linked Azure SQL server by T-SQL statements.
About SQL Server linked server, please see: Create Linked Servers (SQL Server Database Engine)
Hope this helps.
We are in the process of migrating our SQL Server database to Oracle. Some business users have an Access DB with tables linked to SQL Server. Is there a way to change these connections to Oracle, and if so, is there a way to do that so the queries do not have to be updated to reflect the new source?
One of the issues I'm running into is the name of the existing linked table is DBO_TABLE1 (SQL Server connection). When I try to repoint that to Oracle, there is a different schema (let's call it SCHEMA1), so it doesn't recognize the name DBO_TABLE1.
It looks like I'd have to create new connections for each of the linked tables, which is going to be tedious because there are a lot of tables as well as many queries that will need to be modified to use the new table names.
Any help would be greatly appreciated.
I'm new to SQL Server and trying to automatically update tables in SQL Server from tables in MS Access.
I have an Access database of metadata that must be kept updated for sending records to other groups. I also have a database in SQL Server which also has these same metadata tables. Currently these tables in the SQL Server database get updated manually by exporting the Access tables as Excel files, and then importing them into the SQL Server tables.
It's not the most efficient process and could lead to errors in the SQL Server database if someone forgets to check that they are using the most recent data from Access. So I would like to integrate some of the tables from Access to my database in SQL Server. Ideally I would like for the tables in my SQL Server database to be updated whenever Access is updated or at least update the tables automatically in the SQL Server database when I open it.
Would replicating the Access tables be the best? I am using SQL Server 2014 Developer so I think I have this capability. From my understanding, mirroring is for an entire database not just pieces of it. However, I do not want to be able to alter the metadata from SQL Server and have it reflected in Access. I cannot tell if reflecting the tables would do this...?
I also looked at this post about writing multiple insert statements but was confused (What is the best way to auto-generate INSERT statements for a SQL Server table?). Someone else suggested importing all the data into SQL Server and then using an ODBC driver to connect the two, but I'm also not sure how this would update the database in SQL Server anytime Access is updated.
If you have any suggestion and a link to easy to follow tutorial I would really appreciate it!
Thanks
In Access, go to 'External Data', ODBC Database, and connect to the SQL Server database directly - make sure you select 'Link to the data source by creating a linked table' on the first page of the wizard. Now, this linked table is available in Access, but is actually the SQL Server table.
Get rid of the local Access tables, using the new linked tables in their place in whatever queries, forms, reports, etc that you have in Access.
Now, any changes to the tables you see in this Access db ARE changes to the SQL Server database.
I have some Access tables with many number of fields. I have migrated each access table to 6 or 7 sql server tables. I am using sql server 2008. Now I want to use Access as the front end so that I can enter the data in access but it will be stored in sql server. I know that I have to make a ODBC connection. But I am not sure of how to create a access form to use it as a front-end. I am sorry if it's a basic question...
You will probably want to start with an empty Access database (since the table structures and any existing forms and reports will not match what you created in SQL server).
First step is to establish an ODBC connection to your SQL Server database. Then you will "link" the tables in SQL Server to your Access database.
Now, you have an Access database with all the tables that you linked from SQL Server. Those tables still "live" in SQL Server and when you edit them in Access the data will be stored in SQL Server.
You can then build Access forms and reports using these tables just as if the tables were native to Access.
The most versatile way is to use ODBC links to your SQL Server tables and views. That approach allows you the flexibility to link to other ODBC data sources, tables in other Jet/ACE database files, create Jet/ACE tables locally in your database, link to Excel spreadsheets, and so forth. You can incorporate a broad range of data sources.
If you choose ADP, you will be limited to OLE DB connection to a single SQL Server instance. And you will be essentially locked in to SQL Server. You would not be able to switch the application to a different client-server database without a major re-development effort.
Regarding deployment overhead with ODBC, although you may find it convenient to use a DSN during development, you should convert your ODBC links to DSN-less connections before deployment. That way your user's won't each require the DSN. See Doug Steele's page: Using DSN-Less Connections
Well you can create an ODBC connection. You can also create an ADODB connection as well. If your objective is to update or modify a SQL database, both connections will do the trick.
Now, I guess you have to get familiar with the corresponding objects. These should be tables, queries, commands, etc .., that will allow you, for example, to build recordsets out of SQL queries ... Once you are clear with that, you can, for example, assign a recordset to a form through the Set myForm.recordset = myRecordset.open ... method.