I am trying to create SSIS package for loading the data from SAP BW to SQL Server. But after read through many books people are saying we need Data Provider to load the data from SAP BW to SQl Server. Can some suggest me where can i get these Providers for ssis.
A good article on SSIS with SAP Connectors directly from Microsoft:
http://social.technet.microsoft.com/wiki/contents/articles/ssis-with-sap-connectors.aspx
Generally useful page, you can find a SAP connection manager for download here: http://ssisctc.codeplex.com/
You should probably bookmark the second link as it has a wide range of SSIS tools that will definitely be useful for you.
Related
My current model looks like this:
Gather disparate data sources and import into SQL Server.
Process and transform data using SSIS packages.
final step in the SSIS package uploads data to the data warehouse.
BI tools pull data from the data warehouse for end users.
Is this a logical work flow? I initially was going to use data factory and the Azure SSIS integration runtime to process data. However I didn't understand why these steps were needed, as it would seem simpler in my situation just to build my SSIS packages on premises and upload the processed data to my data warehouse. What benefits would I gain from using data factory and the integration runtime? My main concern is that my current model will make automation difficult but I'm not entirely sure. Any help is appreciated.
Your possible paths here would be SSIS on prem, SSIS on VM in Cloud, SSIS in ADF or natively build the pipelines in ADF.
ADF is an Azure Cloud PaaS managed service for data movement and data integration orchestration. To reach back into on-prem data sources, you need to use an Integration Runtime gateway on the source side. So, if you are looking to move to a Cloud-first architecture or migrating into Azure, ADF is a good solution (use V2).
If you are remaining all on-prem SSIS on-prem is the best scenario.
If this is hybrid, where you will continue to have some data on prem and load Azure Data Warehouse in the Cloud, then you can still use SSIS on prem with connectors into ADW as the target. Or if you have to eliminate the local server concept, you can run that SSIS in a VM in Azure.
If you want to eliminate both the datacenter server and the need to patch, maintain, etc. the SSIS server, then use SSIS in ADF, which provides SSIS as a Service. In that case, you can still move data in a hybrid manner.
It really is going to depend on factors such as are you comfortable more in Visual Studio to develop SSIS jobs or do you want to build the pipelines in JSON in ADF? Do you have a plan or a need to move to Cloud? Do you want to move to a Cloud-Managed service (i.e. ADF V2)?
I hope that helps!!
I use several Microsoft Access databases on a regular basis to create reports. To get the source data, I currently have to log in to SAP BW (via SAP NetWeaver), run the source data report, export the results as a .csv file (but actually saving it as a .txt file), and then import that file into Microsoft Access. Is there a way that I can have Access pull the data from SAP BW directly?
Any help is appreciated!
All of the databases used by SAP are industry standard databases and the data is thus going to be stored in a system that supports ODBC.
As far as I know, SAP in general uses Sybase which is also what SQL server was originally based on.
So SAP is running on an industry standard SQL server (Sybase or SQL server). If running on IBM, then the data is in DB2 (often the as400 system).
You thus simply need to contact your IT department and obtain the required ODBC connection strings to the database. You “might” also need to install the latest Sybase drivers if you not running SAP on SQL server but again such information would be available from your SAP support folks.
So you simply setup linked tables in access to the SAP database, and thus no export or download or importing of data is required – you be reporting on live data at all times. The “challenge” is thus of course to grasp the table structures in SAP - a LARGE challenge since in most cases a report you been using for exports is the result of MANY related tables joined together into a "easy" view for exporting. So be prepared for some complex quires to get the data the way you want.
I need to build a Data Warehouse for an existing SQL Server database. I already have the design of the star schema dimension and fact tables. My question is:
Is there a tool in SQL Server 2008 Enterprise to help me with translating my data from the transactional database into the new data warehouse database? I am looking for a tool that helps me cleanup my data and populate the warehouse tables. I have done this before in an academic environment using Oracle databases. In this case I had to do everything "manually" with SQL.
You must check IMPORT and EXPORT functionality of MS - SQL SERVER, watch this video:
http://www.youtube.com/watch?v=eDfhTPU7P-M
you should learn SSIS (not that hard) but first step is to load data. Quick and dirty way to do this is Import/Export Wizard - once you go through its steps, you can even save it as SSIS package and then tweak it as needed.
Some developers use SSIS heavily specifically data flows to clean-up and conform data. Some developers use SSIS only to bring data to a staging area (tables) and then would use SQL Stored procedures to transform/manipulate data on SQL Server.
I've seen many solutions to sync SQL Server data TO SharePoint, but nothing to sync SharePoint lists to SQL Server.
Does anyone know of a solution? Commercial is fine.
Alternatively, I'll need to write a web part that creates relationships between multiple SharePoint lists. Unfortunately, Some are InfoPath libraries with no lookup fields so I can't use the SPQuery CAML joins.
I've found the Camelot .NET Connector but the syntax doesn't seem to support joins, and the SLAM! SharePoint List Association Manager which may work for me but would rather just sync the data to SQL Server and create my reports from there.
EDIT:
SLAM! SharePoint List Association Manager does what I was looking for in real time.
You can write your own SSIS ETL process to extract the list data from SharePoint and load it into SQL server tables. There is a free SharePoint list adapter on codeplex to assist with this. Take a look at SharePoint List Source and Destination
I have an Interbase DB. How can I convert it to SQL Server?
You could use SQL Server built in Data Transformation Services (DTS) in SQL Server 2000 or SQL Server Integration Services (SSIS) in SQL Server 2005.
Try setting up an ODBC DSN for Interbase. Then in DTS / SSIS use the Other (ODBC Data Source) and the DSN.
If that does not work then see if Interbase has a utility to export to text files and then use DTS / SSIS to import the text files.
If you want to spend some money, this will do it:
http://www.spectralcore.com/fullconvert/tutorials/convert-interbase-firebird-to-mssql-sql-server.php
The Interbase DB Wikipedia page says that it supports OBDC and ADO.NET, so I would think that SQL Server can probably import this database on its own. I don't have access to an Interbase DB installation to try, but you might find these pages helpful.
MSDN on import data wizard
MSDN on bulk import command (if Interbase DB can dump a text file)
Article on bulk importing from an ADO.NET supporting source
Hopefully somebody will have direct experience with this database and can help. Good luck!
If you only need to convert tables and data, that's rather simple. Just use ODBC driver for InterBase, connect to it and pump the data.
However, if you need business logic as well, you cannot covert it just like that. You can convert regular tables and views without too much problems. Domain info would be lost but you don't need it in MSSQL anyway. The only problem with tables can be array fields, which you need to convert to separate tables, but that isn't too hard either.
The problem is the conversion of triggers and stored procedures, since InterBase uses its own, custom PSQL language. It has some concepts that are different from MSSQL. For example, you have procedures that can return resultsets, and you would need to convert those to MSSQL functions.
In any case, it shouldn't be too hard, since you're going from low to high complexity, but there are no tools to do it automatically.