Here's my setup:
SQL Azure DB - This is the PaaS solution, not SQL Server running on an Azure VM.
Single Page App (Angular.js) hosted on Azure Web App.
My needs:
I'd like to find a packaged solution where we could allow user-configured reporting that could be saved by the user, for running later. Output would ideally be either CSV or PDF.
Initial thoughts:
Could we create a SQL Server installation on an Azure VM, and use SSRS with the SQL Azure DB as the data source?
Are there third party solutions that could meet these needs?
My research so far has shown one answer... migrate your data to SQL Server running on Azure VM, and use SSRS that way.
Any additional suggestions? I'm reluctant to do a data migration if I can avoid it.
Consider PowerBi, there are numerous examples on the web and here is an overview. What you basically get is an excel-like environment with a lot of smart and easy visualizations. I am not sure how well it works, but there is a possibility to ask questions about your data in natural language as well.
It should be pretty easy to connect your database to PowerBi, then your user can configure what kind of visualizations/report does he want to have.
Related
I'm trying to find out how I can use a Microsoft Azure Machine Learning notebook to connect to SQL Server and Azure SQL databases.
I am aware of how to connect to SQL Server databases with regular Jupyter files with the use of ODBC connections. But, it looks like I have to try something different when using Azure Machine Learning notebooks.
Could someone describe the best approach to accomplish this?
Note: I am referring to the new Microsoft Azure Machine Learning service, which is currently in preview mode as of May 2020.
great question -- the answer depends on whether or not your data sources are in Azure.
data in Azure
for Azure based storage (blob, data lake, Azure SQL, Azure Databricks) you're in luck with Azure ML Datasets, and abstraction on top of azureml-dataprep, a component package of azureml-sdk. IMHO, Azure ML Datasets are slick, TabularDatasets in particular with their to_pandas_dataframe() and .to_spark_dataframe() methods.
Check out the following articles for guidance on how to:
How to connect to data and register as a Dataset
How to access data during training
Follow the recommendations in this tutorial recommendation would be to make a TabularDataset FileDataset
data not in Azure
For on-premise or IaaS SQL servers, you've got two options that I'm aware of:
Put your SQL server inside the same network at the Azure ML service and ComputeTarget and access the server directly with pyodbc library.
Use ADF to move the SQL server data to Azure Storage, (you'll need an ADF integration runtime on the SQL server)
I'm attempting to find a good read on how to connect our Azure DevOps reporting data that drives the reports within DevOps to our internal SSRS. Having not done this before, I'm curious if this is even possible or if I can just obtain a connection string/WebApi somewhere with a list of tables/JSON. The current reports offered by DevOps are not extensive enough for our need and we need to expand upon them and would prefer to do this in house.
Thank you.
The SQL Server reporting solution is based on a data warehouse and OLAP cube coupled with a SQL Server Reporting server to host reports.
Currently ,integration with the data warehouse and SQL Server
Reporting Services is only supported for on-premises Azure DevOps
Server 2019 and Team Foundation Server (TFS). If you don't have a
reporting site and want to add it, see Add reports to a project.
For information on what is supported for Azure DevOps Services, see Dashboards and reports overview.
This is stated in this official document, for details,please refer to it.
If you want to integrate SSRS with Azure DevOsp Service , it is currently unachievable . You could add your request for this feature on our UserVoice site , which is our main forum for product suggestions. In addition, you could also vote that suggestion ticket and share your comment there, so product team would provide the updates if they view it.
Following is the exact scenario in my application:
SQL Server database is hosted on-premise locally in US office for
development purpose.
Developers are distributed in 3 different regions (US, India and
Australia).
Developers from India and Australia faces a lot of delay while
trying to access the database from application.
In order to resolve the above issue, we identified a following approach -
Create a VM and install SQL Server there.
Restore database over there.
US developers would continue using the database deployed in their
environment.
India and Australia developers would use the SQL database instance
hosted in Azure VM.
In order to enable synchronization of data and schema between these two databases (Azure VM SQL, and On-prem SQL instance), we are planning to use Azure Data Sync.
I believe most of the things in above scenario are subject of research. But guidance of someone who has already worked on similar things would be very much helpful. Also, we are not using Azure SQL because that would require changes in database schema, as its very old and legacy database
Could you please suggest if the above approach is ideal or not? Note, this is only for the ease of development, and we are not moving our production database outside on-prem setup.
I would not attempt to use Azure Data Sync here, first because you are not otherwise using Azure SQL Database, and second because it's not intended to sync schema changes like this.
Instead pick a primary replica for data changes, and periodically ship and restore backups to refresh the secondary instance. For schema changes, use SQL Server Data Tools and your Source Code Repository (Azure DevOps) to manage the changes.
I recently started a Winforms VB.NET application that uses a mysql database to store information. Problem is this is a standalone system no network access to the database is needed. And installing mysql server, along with the connector has become a great burden. Is there a viable alternative database engine that will be non-transactional, and EF still works with. This database just needs to keep up with client details, payment History, and related items..
SQL Server Compact might work for you, depending on it's limitations. If not, SQL Server Express will work fine
I have a client that runs a small business. They need a custom database solution and I'm looking into various options. My experience is limited to .NET using local SQL Servers (no ASP.NET), however, this client is non-technical and would benefit from being able to outsource the DBA tasks. I'm a complete Azure noob, I just scanned the tutorials and they all appear targeted at developing MVC ASP solutions. The client doesn't need a browser based solution. A fat desktop client used from different geographical offices would be the least expensive option I can deliver. I'm just trying to save some time going through all the tutorials and docs only to find out that this isn't what SQL Azure is intended to do. In effect my questions boil down to:
Can I develop a C#/.NET WPF desktop application using Entity Framework 4 and have it hit SQL Azure instead of a local SQL Server?
Are there any known gotchas with EF4 and SQL Azure?
Are there other hidden development costs/complications in using SQL-Azure instead of a local SQL Server.
Is the basic tool support the same? One specific example I can think of; do I get a SQL profiler tool for troubleshooting?
The final question is security related and I'm not sophisticated enough to ask a good question, but is hitting a SQL Azure db this way considered a security no no?
Yes, you can, but a more suitable approach would be to use WCF Data Services or another form of web services (asmx or WCF) as a services layer for your application. I like this approach for line of business applications. I hate web apps for line of business and by using a services connected WPF desktop application, you get the benefits of running in the cloud and having a cloud offering without the necessity to be HTML based.
SQL Azure has full support for EF these days. In the past there were some issues, but I have not encountered any these days.
In terms of development costs and complications - the Azure desktop hosted environment is a bit of a PITA from a development perspective, but I haven't had major problems. You lose the ability to share a local DEV SQL Server unless you use a hosted instance....of course there's a development cost in that because you have to pay for usage.
Good point! SQL Azure does not provide SQL Profiler support at present. I personally use the built in EF tracing support for this functionality.
Exposing a SQL Azure DB directly isn't a good idea from a security perspective. That's why I suggest hitting a WCF Data Services (or other web services) endpoint in point 1.
You can develop a desktop or on-premise application that uses SQL Azure for your database.
You need to take the standard Azure precautions - assume that connection failures will occur and ensure that your application has retry logic to restore operation. Also note that SQL Azure will terminate any operations that take longer than a minute, to preserve the service for other users. If you have lots of data and some nasty queries, that might be relevant.
EF works fine with SQL Azure. There are some limitations to SQL Azure, itself, which you can read about from the documentation on Microsoft's web site. If you design you database for Azure, it'll work fine on SQL Server or SQL Express (but not necessarily the other way around).
In addition to the monthly charge for the database, you will pay for data that leaves the data centre. Design your application carefully to minimise the amount of data that is retrieved from the database. You no longer have to pay for data going into the data centre, which helps.
You can still use SQL Management Studio and Data Connections within Visual Studio. No SQL Profiler, though. There are a few irritating things you can't do with Management Studio, but nothing insurmountable.
You will have to open up firewall rules for access to the database, but hopefully, they'll be limited. Authentication is by SQL Server credentials, not integrated authentication.
I wouldn't tend to do it this way, but it works.