Is there a way to connect SQL Server 2008 R2 to the Azure Data Marketplace to enable data import?
Are there any ODBC or JDBC drivers for the Azure Data Marketplace?
I'm a bit confused by the question. Is this about publishing data through the Windows Azure Marketplace and sourcing it from SQL Server? Or is it about accessing published data from an application and bringing that data into your own app?
If the former:
You may choose to host your data in SQL Server. When you sign up for data hosting in the Windows Azure Marketplace, you'll provide the requisite connection strings for your servers. You don't have to worry about ODBC/JDBC drivers. See the data publishing documentation for more details.
If the latter: Data may be accessed via HTTP/OData, not ODBC/JDBC. It's a metered consumption model, so you need to subscribe to a particular data feed, which then gives you an access token. Check out this video from TechEd last year to see more about this, along with a .NET code sample. You can easily access data from any other language as well.
If your goal is to access the data feed directly from SQL Server: I'm no expert in CLR Stored Procedures, but if CLR SP's supported code that can access a web service endpoint, I guess you could write a CLR SP to access a data feed, pull data down, and populate local tables. I have no idea if this is supported or advisable...
Related
I have a ODBC datasource and I'd need to use it with PowerBI. It works fine locally.
In order to refresh data and keep user up to date, I need to send this data do cloud (Azure/BlobStorage) then PowerBI can connect directly into Blob Storage and consume the data.
As discussed here stackoverflow-topic , we need an on-premises server to have this ODBC running.
It sounds a quite confusing to me as we need the data on cloud, using ODBC as datasource and "publishing" the data with Blob Storage, and for that, we do need a local server.
I'm very begginer with Azure Cloud but... don't we have any other way to have this process configured without local server or a expensive Virtual Machine on Azure? Looks like we are running in circles here.
Thank you!
Your options:
Install Power BI Gateway (standard mode) on a server to host the ODBC driver
Install Power BI Gateway (personal mode) on your PC to host the ODBC driver
Copy the data to Azure (Blob Storage or Azure SQL Database, etc), and configure the Power BI Model to load the data from there instead of ODBC
Manually refresh your data in Power BI Desktop and re-publish it to Power BI whenever the data needs to be updated.
For Option 3 you can use any tool you want to copy the data to Azure. Azure Data Factory is one option, and for that you would need to install the Self-Hosted Integration Runtime to host the ODBC driver. But you can also extract the data to files and copy them to Auzre Storage with AzCopy.
I would like to know what extra benefits one get by choosing Azure SQL Managed Instance compared to Azure SQL DB PaaS. I know SQL Managed Instance is offered as a vCore based purchasing model only. Apart from this what is the extra add on and benefits that one gets over the other. Any reply would be appreciated.
With Azure SQL Managed Instance, you essentially get a full fledged SQL Server that you can control any way you want, just like you would control a locally configured SQL Server. All the power and access and customization you want.
With, Azure SQL DB PaaS, you are essentially getting a database service, so, you give up a lot of control.
For example, take server collation. With the database service, SQL_Latin1_General_CP1_CI_AS , is all you get. With the Managed Instance, its your server. So, go ahead and select whatever collation you want, just like how you would select the collation at the time of creatoin.
Another issue is with auditing, if that is something that is important to your setup. with SQL Managed Instance, auditing happens at server level, because, you are getting the full database server. With the database service, it only database, because, you are only getting a database.
These are just the main details that I found. more details here at this Azure doc - https://learn.microsoft.com/en-us/azure/azure-sql/database/features-comparison
Of course, Managed is going to cost you more because you are paying for the license of the SQL server too.
Lastly, for me, this is the almost (not the exact same thing) like you running your own File Server on a Windows VM on Azure (Managed Instance) versus, just using Blob Storage. In both cases, you are just trying to store some files, but its how much control you have.
I would say think about Azure SQL DB vs Azure SQL Managed Instance (MI) as
Azure SQL DB = Resources dedicated to individual DBs like a container. They are grouped under a Azure SQL Server but that SQL Server is just for grouping.
Azure SQL MI = Almost same as on-prem SQL Server except you don't have to worry about OS, backups, high availability.
Here is a good comparison.
https://learn.microsoft.com/en-us/azure/azure-sql/database/features-comparison
Hopefully this will help
Azure SQL Database - The usual PaaS way. You have vCore, DTU, and Serverless billing mode. And Elastic pool support.
Azure SQL Managed Instance - Similar as below. When you want to use instance-scoped features of Azure SQL Managed Instance like Service Broker, CLR, SQL Server Agent, and Linked servers. As if you have an SQL Server on premise, Azure is responsible for patching, upgrading version etc.
SQL Server on Azure Virtual Machines - Similar as above. But you are responsible for OS and SQL server upgrade.
I have recently started using MS Power BI, and have come across a problem which seems inconsistent, and the answer likewise.
I am connecting to an Azure SQL database, and therefore have chosen this as the data source in the desktop app. Everything seems to be working just fine, and I can create tables, graphs and whatnot. One thing is off, though: When I choose Azure SQL DB as the source, the connection dialog box does not appear to be any different than if I just choose (non-Azure) SQL DB. Puzzling.
The other thing, which is actually the main issue: In Power BI (the website), I can open my published reports, but some of them don't show up, and I get an error message in a pink bar at the top, saying the data source is not available because the gateway can't be reached. I am well aware of this, because I have deliberately stopped the gateway service (PBIEgwService) running locally, because I have read several places that if the data source is Azure, an on-premises gateway is not needed. (E.g.: "Question: Do I need a gateway for cloud data sources like Azure SQL Database?
Answer: No! The service will be able to connect to that data source without a gateway." here: https://learn.microsoft.com/en-us/power-bi/service-gateway-onprem-faq)
So in short: Why does PBI not (always) connect directly to Azure?
And yes, I have checked the credentials. I can connect just fine in PBI desktop.
Are you allowing Azure Services to connect in your Azure SQL firewall?
https://learn.microsoft.com/en-us/azure/sql-database/sql-database-firewall-configure#manage-server-level-ip-firewall-rules-using-the-azure-portal
I am trying to get to grips with Azure Mobile Services and am a little lost about which Azure services I should be using for what. When you set up a new Azure Mobile Service you only get the option to create it with Microsoft SQL Server as the database. Can you configure it to use the documentDB service instead?
Also a lot of what I read about Azure Mobile Services seem to be setup around storing data for a particular user. Is this the correct place to store data and query it for all the systems users rather than an individual or should that be handled elsewhere?
thanks
Andy
using the .NET backend, you have a choice of using Azure SQL Database,MongoDB or Table Storage. There's no out of the box support yet for DocumentDB, but you can make it work as shown here
what you store in the storage listed above is up to you, there is no specific reason/restriction/limitation that's its only for user specific data. the samples just happen to show that.
You may use any backend database service. It's true you have to set up SQL when you create a new mobile service space. And the SDK has a Table provider that maps to SQL (or MongoDB). However, you can ignore all that if you want. As long as you can access the appropriate driver for your database-of-choice, you can make calls to the database from the API backend methods. This is especially true when building custom API methods.
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.