Tricky question - Does anyone know where the ORM SQL code lives that the Azure Dev storage emulator uses for Table Storage?
I'm wanting to implement a SQL version of Azure Table storage for use on-premises (outside of Azure).
And before explaining to me the differences between a relational db like SQL Server and a NoSQL key/value store like Azure Table storage - I know already, thanks :)
Go to the SQL server you installed the Storage Emulator. You will see a database called "DevelopmentStorageDb20110816" if you have installed the Azure SDK v1.5+ (It was a different date previous to that - something like DevelopmentStorageDb20090919 I think).
In that database you will find all the tables, stored procedures and functions needed to emulate Windows Azure storage.
Related
Is it possible for me to insert some data from one database to another in Azure sql?
Let's say I have a trigger in db1 that updates some values in db2.
I read about elastic queries but it seems like they are read-only so they don't solve my problem.
You can't use cross-database in Azure Sql Server because databases can't see eachother physically , you could use elastic pools but they are Read Only.
A solution is to use SQL Managed Instance to upload your instance . This supports cross-database queries but it was expensive.
There was some previous discussion here about doing similar:
C# Azure Function trigger when SQL Database has a new row added without polling
There is also the Azure SQL Bindings for Azure Functions but they are input bindings and not triggers and they're still in preview and limited to C#, JavaScript and Python.
Azure SQL bindings for Azure Functions overview (preview)
There was a new announcement last week after MS Build however for Azure SQL Database External REST Endpoints Integration (hopefully they don't refer to it as ASDEREI) but this is currently in preview under Early Adoption Program (EAP).
Announcing the “Azure SQL Database External REST Endpoints Integration” Early Adoption Program
Okay so I figured since Azure has a lot of tools and I am failing at best processes to just ask on SO.
What I can do:
BACPAC creation
Creation is directly from SSMS with hovering over the database in Object Explorer. Right Click>Tasks>Export Data Tier Application. Choose a disk location. The caveat is generally to not have a database that is in use querying. So have a copy or system that can be not using the database.
BACPAC restore to Azure
SqlPackage.exe https://learn.microsoft.com/en-us/sql/tools/sqlpackage?view=sql-server-2017
When I do it it is similar to: (must have Visual Studio or equivalent Sql management object DLLs installed)
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130\SqlPackage.exe" /a:Import /sf:(bacpac Location) /tdn:(dbName)/tsn:bvtest.database.windows.net /tu:(user) /tp:(password)
In Azure>SQL Servers>(Top ribbon)>Import database>(have blob storage with a bacpac created to it already). This method appears slightly faster if they are both on same region.
My question is that I have seen articles like this one: https://learn.microsoft.com/en-us/sql/azure-data-studio/tutorial-backup-restore-sql-server?view=sql-server-2017 as well as knowing SSMS pretty well. It seems all options to restore to Azure SQL PAAS are turned off for a 'bak' backup and you have to make a bacpac for going instance to Azure PAAS. The problem is that this takes hours just to make the bacpac on a relatively medium sized database of 120 gigs. Then it takes hours to restore. Other than what I have tried above is there a faster way?
You can use Azure Data Migration Service (ADMS) instead of importing/exporting bacpacs. Azure Data Migration Service allows you to migrate data from SQL Server to Azure SQL Database with no downtime if your database does not have "heaps". If your database has heaps you will have to perform an offline migration. Copying/migrating data from a SQL Server ARM (IaaS) Premium Storage (200 GB / 790 tables) to an Azure SQL Database (Premium) takes 1 hour 40 minutes with an offline migration. That is the fastest data migration I have seen as a workaround to import/export bacpacs since SQL Server native backups are not supported on Azure SQL Database (DTU-model / Vcore model).
ADMS performs a validation of your data at the end, if you want.
Recently I was informed that Azure SQL V12 now supports
databases that use encryption. I have tried all methods documented here,
https://azure.microsoft.com/en-us/documentation/articles/sql-database-migrate-ssms/
When attempting to migrate a database I get these kind of errors:
[dbo].[someitem] cannot be deployed as the script body is encrypted
Here is a recent response from an Azure AMA,
https://www.reddit.com/r/AZURE/comments/3o1ea9/ama_azure_app_service_team_109/cvu7xco
what am I doing wrong to get this feature working? As I believe I have performed all the steps as documented.
Azure SQL Database V12 supports two types of encryption:
Transparent Data Encryption as documented here: https://msdn.microsoft.com/en-us/library/dn948096.aspx.
Cell Level Encryption: https://msdn.microsoft.com/library/ms179331.aspx and http://blogs.msdn.com/b/sqlsecurity/archive/2015/05/12/recommendations-for-using-cell-level-encryption-in-azure-sql-database.aspx
Which of these are you trying to use?
Do you need to migrate the database between 2 different Azure SQL DB servers or between an on premise SQL Server and Azure SQL DB?
Between 2 Azure SQL DB servers, you can do a true backup restore via CREATE DATABASE ... AS COPY OF... syntax (https://msdn.microsoft.com/en-us/library/dn268335.aspx). This works because the key is in the database backup.
Between SQL Server and Azure SQL DB, there is no term plan to support moving of encrypted procedures or views.
If you could elaborate why you are encrypting procedures and views, that would help us understand the problems you are trying to solve. Many of the scenarios we've encountered in the past where customers desired procedure and view encryption with SQL Server don't apply to Azure SQL Database, but we're always learning of new challenges people have protecting their databases.
My website is a .net 4.5 mvc site built with VS 2012. I have a SQL Server Compact DB in my app_data folder. All works great on my localhost. I deploy to Azure website and get this error?
Unable to find the requested .Net Framework Data Provider. It may not be installed.
I've googled it and get lots of possible answers, but none specific to Azure and SQL server compact. So my question is simple. Does a windows Azure Website which is deployed to an Azure shared hosting server support SQL Server Compact? If so, what do I need to do to eliminate the aforementioned error and make it work?
It certainly is possible to use SQL Server Compact on Windows Azure. However, you need to ask yourself:
Will I change anything in database?
This includes adding, updating and removing data. If you do, you should not use SQL Server Compact on Windows Azure. Because, if you use SQL Server Compact on Windows Azure and change anything in the database, you'll run into two problems:
Data is not replicated.
You risk losing data.
Data is not replicated
If you change anything in the database, the changes stays local. This means that if you have multiple instances running your web application, then each web application will have their own database, and if you change something in one of them, the change won't be replicated to other instances, which will result in unpredictable behaviour in your application.
You risk losing data
If you change anything in the database after deployment, you risk losing data, because Windows Azure might decide to redeploy your instance to another virtual or physical machine. When this happens, the new instance will be setup with the deployment package you originally uploaded to Windows Azure, and this package does not contain any changes you make to the database. And this redeployment can happen at any time for several reasons.
Conclusion
So, SQL Compact on Azure? Sure, no problem if your data is read-only. However, note that you won't get the performance you would with SQL Azure. But if your need changes down the road, you can always migrate your application from SQL Server Compact to SQL Azure.
If you want to use SQL Server Compact with Windows Azure, you can use the "private deployment" method, as explained on "ErikEJ"'s blog.
Edit: Microsoft has announced that they now provide 1 free 20 MB SQL Azure Database for every Azure subscription. This means you can create a subscription and create a free website, with a free SQL Azure Database. (As long as it's less than 20 MB) You can also have multiple Web Sites associated with the same SQL Azure Database for free. So, if you're considering SQL Server Compact on Windows Azure because your database will be very small and you don't want to pay for a 100 MB database, you can consider this option. In most cases, it will be a better solution. Your website will perform better, your database performance will be better and you have the ability to change your data and it will be replicated.
It's possible for SQL Server Compact 4.0 on Azure!!
I write an an article for it
And this is the English version I found
By few step:
Below is the solution after my research:
Step by Step like this:
Install two nuget: EntityFrame.SqlServerCompact & Microsoft SQL Server Compact Edition
put your SQL database file(.sdf/.mdf) in APP_Data folder
(Put the connection string like this in order to use it:
<add name ="DefaultConnection" connectionString ="Data Source=|DataDirectory|CompactDB.sdf" providerName ="System.Data.SqlServerCe.4.0" />)
Publish full project include above SQL database file to AzureWebsites.
you can find it can work well and is totally free.
Second Wenchao Zeng of Microsoft the Azure don't support Sql Compact.
I could use once but this is not recommended because the Windows Azure work with replication of the data (this is the cloud, remember?) and the Sql CE does not support this functionality. If you can to put a Sql CE in Azure sometimes will not get access or users see data outdated or broken because the async.
The best way is you to use the Azure Sql ou BLOB storage.
I'm developing a .NET app, which needs to run both on Azure and on regular Windows Servers(2003). It needs to store a few GB of data and SQL Azure is too expensive for me, so I'll use Azure tables in the cloud version. Can you recommend a storage solution, which will run on standalone servers and have an API and behavior similar to Azure tables? From what I've seen Server AppFabric does not include Tables.
If you think what Windows Azure Table Storage is, it is a Key-Value pair based non-relational databse which is accessible through REST API. Please download this document about Windows Azure and NoSQL database details.
If I were in your situation, my approach would have been to find something similar to Azure Table Storage which I can access over REST and have similar accessibility API. So if you try to find the similar database to run on a machine you really need to look for:
Key Value Pair DB
Support for basic operations i.e add, delete, insert, modify an entity
Partition Key and Row Key based Accessibility
RESTful Interface to connect
If you would want to try something you sure can look at:
DBreeze (C# based Key Value Pair NoSQL DB) I just saw it and looks exciting
Googles LevelDB (Key Value Pair DB, open source and available on Windows) I have no idea about API
Redis (Great Key-Value Pair DB but not sure for Windows compatibility and API)
Here is a list of key/value databases without additional indexing facilities are:
Berkeley DB
HBase
MemcacheDB
Redis
SimpleDB
Tokyo Cabinet/Tyrant
Voldemort
Riak
If none works, you sure can get any of open source DB and modify to work for your requirement and then make that available to others as your contribution to community.
ADDED
Now you can use Windows Azure Virtual Machine to run any kind of Key-Value pair DB on Linux or Windows Machine and connection with your application.
I'm not sure which storage solution to recommend, but just about any database solution would work provided that you write an Interface to abstract all your data storage code. Then write implementations of that interface for Azure Table storage and whatever other database you want to use on the non-cloud server
You should be doing that anyway so that your code isn't tightly coupled with Azure Table Storage APIs.
If you combine coding against that Interface with an IoC container, then a single line of code or a single configuration setting would enable you to switch between data implementations based on which platform the code is running on.