Sql Server reporting services over bcp - sql-server

Currently in our organisation we aren't using reporting services in Sql Server anywhere. I have a task where i need to fetch data using a query and dump it to some local drive on daily basis. All the dump task currently are done using bcp utility.
I want to know if this task can be done using Sql Server Reporting Services.
PS: i have read a lot about reporting services but i am not clear
1. if we can dump file on daily basis like a job does.
2. if we can add parametrised query to fetch data and pass parameters in configurable way.
please suggest if using reporting services would be beneficial in my case?

SQL Server Reporting Services is used to create and manage reports. It does not do administrative tasks, like execute jobs or scripts. So to answer your questions:
No, you cannot dump files on a daily basis, that is what SQL Server Agent does.
Yes, SSRS reports can accept parameters, but only to dynamically display data. There is nothing here in the way of executing BCP.

Related

Is it possible to execute a Data Factory Pipeline as a step in a SQL Agent Job on Azure Managed Instance?

I've currently got an ETL process that dynamically builds and executes sql jobs based on job steps that are saved in my database. Included in these jobs are steps to call SSIS packages that move data from one server to another and/or call stored procs on target servers to do further processing. I'm looking at what it would take to migrate our process from SQL Server to a Azure Managed Instance. One of the specific things I'm looking at is the feasibility of replacing the steps that call the SSIS packages with steps that execute Azure Data Factory pipelines or other ADF actions that accomplish the same results. So far I have not run across any examples of this. Anyone have any experience with accessing Data Factory functionality with SQL Agent jobs?
You can run powershell scripts via SQL agent as mentioned in below MSFT docs:
https://learn.microsoft.com/en-us/sql/powershell/run-windows-powershell-steps-in-sql-server-agent?view=sql-server-ver16
And via powershell and ADF REST APIS, you can trigger the ADF pipelines

Automate Azure SQL Server database restores

I have two SQL server databases running on Azure - one Prod and one Test. I want every night, the Test server will automatically sync its data and structure (include any TABLE, Stored Proc changes ) with Prod - so Test is a mirror of Prod that can be used for development / QA.
I am wondering how to achieve this on Azure? Please note I would like this to happen automatically and on a schedule. Thanks everybody.
Azure the moment, we can use Azure data sync service to sync data between database. But we cannot use the service to sync Stored Procedures. For more details, please refer to here and here. So if we want to sync Stored Procedures, SQL Server Management Studio Generate Scripts Wizard is an easy means of producing a script that will copy all of your Stored Procedures to another database.
Besides, regarding how to create a schedule to start azure SQL data sync, please refer to the blog

Extract from Progress Database to SQL Server

I'm looking for the best approach (or a couple of good ones to choose from) for extracting from a Progress database (v10.2b). The eventual target will be SQL Server (v2008). I say "eventual target", because I don't necessarily have to connect directly to Progress from within SQL Server, i.e. I'm not averse to extracting from Progress to a text file, and then importing that into SQL Server.
My research on approaches came up with scenarios that don't match mine;
Migrating an entire Progress DB to SQL Server
Exporting entire tables from Progress to SQL Server
Using Progress-specific tools, something to which I do not have access
I am able to connect to Progress using ODBC, and have written some queries from within Visual Studio (v2010). I've also done a bit of custom programming against the Progress database, building a simple web interface to prove out a few things.
So, my requirement is to use ODBC, and build a routine that runs a specific query on a daily basis daily. The results of this query will then be imported into a SQL Server database. Thanks in advance for your help.
Update
After some additional research, I did find that a Linked Server is what I'm looking for. Some notes for others working with SQL Server Express;
If it's SQL Server Express that you are working with, you may not see a program on your desktop or in the Start Menu for DTS. I found DTSWizard.exe nested in my SQL Server Program Files (for me, C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn), and was able to simply create a shortcut.
Also, because I'm using the SQL Express version of SQL Server, I wasn't able to save the Package I'd created. So, after creating the Package and running it once, I simply re-ran the package, and saved off my SQL for use in teh future.
Bit of a late answer, but in case anyone else was looking to do this...
You can use linked server, but you will find that the performance won't be as good as directly connecting via the ODBC drivers, also the translation of the data types may mean that you cannot access some tables. The linked server might be handy though for exploring the data.
If you use SSIS with the ODBC drivers (you will have to use ADO.NET data sources) then this will perform the most efficiently, and as well you should get more accurate data types (remember that the data types within progress can change dynamically).
If you have to extract a lot of tables, I would look at BIML to help you achieve this. BIML (Business Intelligence Markup Language) can help you create dynamically many SSIS packages on the fly which can be called from a master package. This master package can then be scheduled or run ad-hoc and so can any of the child packages as needed.
Can you connect to the Progress DB using OLE? If so, you could use SQL Server Linked Server to bypass the need for extracting to a file which would then be loaded into SQL Server. Alternately, you could extract to Excel and then import from Excel to SQL Server.

Best way of logging in SSIS

There are 5 different types of logging in SSIS
Event Log
Text File
XML File
SQL Server
SQL Server Profiler
I am in a production environment where developers do not have access to production systems.
Which logging method should be my poison of choice, and why?
If you're not going to have access to the production server, then SQL Server logging is your best bet by far. You'll have plenty of ways of viewing the logged information, for example via custom SSRS reports or web pages, or direct access to the tables if your DBA allows it. Also, the logs will be easier to search and filter when in a table.
Personally I prefer logging to SQL Server.
I think this is because it puts the data in a form which I can immediately access and process. For example, I can then slice and dice the data, export it to another server, setup agent jobs to monitor the logs and email alerts etc.
Have you looked at BI xPress from Pragmaticworks. They have serious auditing feature for SSIS
SSIS Logging And Auditing, Notification, Deployment using BI xPress

Best way to run a nightly process that manipulates data and sends email via SQL Server 2005

I have an asp app that runs against SQL Server 2005 and I'd like to run processes that:
query data,
manipulate data, and
send emails containing particular data and analysis
What is the easiest way to do this in SQL Server 2005? Can I do this in an SSIS package? Should I use CLR procedures?
You can do this with a SSIS package or better yet with just TSQL.
Can you give us more details if you need further help/ideas?
Maybe, you could meet this scope using Jobs inside SQL Server 2005 (Standard or Higher) and simply executing Queries Stored Procedures. What data and based on which Parameters you need to query?
And what kind of manipulation you need do to? To send the Results you can use SQL Server Mail.
So you'd be completly independent from your ASP app for this tasks.
As others have stated, you could achieve this via either SQL Server Integration Services or a combination of SQL Server Jobs and Stored Procedures.
Personally, I would suggest you look at the SSIS route, as the existing components tasks that are available will provide a significant portion of the functionality that you require, out of the box, thereby speeding up your development process.
If you wanted to get clever with your reporting and deliver results that look really professional, you could define a SQL Server Reporting Services report and call it from within SSIS.
Depending on how complex they are, just go with T-SQL stored procedures, including using xp_send_dbmail to send the email, and then schedule it using a SQL Agent job.

Resources