I've been trying to setup a local test environment by installing Oracle Express Edition. I've got a test database up and running and can query that database from Oracle SQL Developer. I then installed the Attunity Oracle connector. I found documentation that said I should install both 32-bit and 64-bit versions of the Oracle Client for Windows, so this is what I did. Actually these are just zip packages that you have to unzip and add to your PATH environment variable. (Apparently the people at Oracle haven't heard of installers.) I then created an SSIS package, added an Oracle Source component to my data flow and created an Oracle Connection manager for it. However, I'm unable to connect to the XE database. The error I receive is 'Oracle Home not found.'
Any ideas? Is it even possible to do this?
VS2015, SQL Server 2014 Express, Data Tools 14.0.61021.0, Oracle Express Edition 11g R2
#Rubio,
You'll need to set your system environment variables for Oracle on the VM or local box you're running the SSIS package if that's where your version of Oracle Express resides. To determine where that is, the directory path should be one level above the bin directory where the sqlplus executable exists.
Here's an example setting: ORACLE_HOME=c:\Oracle\product\11.2.0. You should also set your path to include $Oracle_HOME\bin.
To set your environment variables in Windows, go to the advanced system settings, click on environment variables, add a new one under system.
Related
I am using VS 2017 SSDT 15.9.20 to create an SSIS package. The package is originally created in Server A where SSDT is installed and the SQL server resides in Server A. So I was ale to create the package in Server A. I created a SQL job in Server A and linked directly to run the DTSX file without deploying it.
What my package does:
In server A my package will read the excel in the location C:\Users\xxx\Documents\myproj\excelfile.xls
and will create excel sheets inside C:\Users\xxx\Documents\myproj\files\ folder.
Deployment:
Now I want to deploy this package to Server B. And my package will read the excel in the location \ServerB\S:\Documents\myproj\excelfile.xls
and will create excel sheets inside \ServerB\S:\Documents\myproj\files\ folder.
My questions:
Should I deploy my project to create dtsx file? There is already a dtsx file inside my project folder. Can I not just move that file to server B and change the connection string and paths? Will it work that way?
SSIS deployent tool does not work for me from server A. It does not identify the destination servers.How can be deployment made easy? How can I change the destination paths?
Server A has both SSDT installed and SQL database resides in same server. But the target server B is a database server and does not have SSDT in it. I will schedule a job in SQL server of server B that will call my dtsx package and execute it.
I am new to SSIS. so please don't close this question and would be great if anyone can help me with these questions. Thanks!
Without knowing the version of SQL, I'll give both answers:
Should I deploy my project to create dtsx file? There is already a
dtsx file inside my project folder. Can I not just move that file to
server B and change the connection string and paths? Will it work
that way?
Versions less than SQL 2012: Copy the dtsx file from your project to the folder on the target server. Connection strings can be change in the configuration of the SQL Agent job or by using package Configurations:
https://learn.microsoft.com/en-us/sql/integration-services/lesson-5-add-ssis-package-configurations-for-the-package-deployment-model?view=sql-server-ver15
Versions greater SQL 2012: Create the ssis catalog on the target servers:
https://learn.microsoft.com/en-us/sql/integration-services/create-the-ssis-catalog?view=sql-server-2014.
Right click on the project and use the wizard to deploy to the target server. Connection strings can be modified in SQL Agent as noted above, or you can use parameters:
https://learn.microsoft.com/en-us/sql/integration-services/lesson-6-using-parameters-with-the-project-deployment-model-in-ssis?view=sql-server-ver15
The latter my seem like more work at first, but there is a myriad of benefits and it is the preferred way of doing things
SSIS deployent tool does not work for me from server A. It does not
identify the destination servers.How can be deployment made easy?
How can I change the destination paths?
Follow either deployment method noted above. Package deployment (copy files to a folder) still works in later versions, but it is less easy to manage and less things done for you like securing configurations and setting up logging.
Server A has both SSDT installed and SQL database resides in same
server. But the target server B is a database server and does not
have SSDT in it. I will schedule a job in SQL server of server B
that will call my dtsx package and execute it.
SSDT has no bearing on SSIS, but Integration Services does. SSDT is a developer tool and really should only be installed on developers machines for the purpose of creating packages and testing. It is better to not have this on the server because it encourages development to happen there and for devs to logon to the server like it's their laptop. Integration Services is a service that comes with SQL Server and is used for executing packages. You'll need to add this service to the instance if you want to execute packages from SQL Agent. This link explains that and gives guidance on installing SSDT locally:
https://learn.microsoft.com/en-us/sql/integration-services/install-windows/install-integration-services?view=sql-server-ver15
Our organization has a Windows server running SQL Server Reporting Services (SSRS). We use SSRS to build reports that access an Oracle database. We were able to get SSRS to connect to our Oracle database by installing Oracle Data Access Components (ODAC) for Windows on our server. We installed the Xcopy versions - both 32-bit and 64-bit (don't know if we needed to do both; SSRS used to only accept 32-bit drivers). We were able to successfully set up a data source in SSRS that connected to the Oracle database.
However, we write our reports on development machines using SQL Server Report Builder 3.0. When building a report that uses a shared data source on the server - the one that accesses our Oracle database, we get the error
The selected data extension ORACLE is not installed or cannot be loaded...
What do we need to do to be able to write reports from our development machines that use a shared data source to our Oracle database?
You need to install ODAC on your development machines as well. Even though you are configuring your report to use a shared data source on the server, Report Builder 3.0 will use connection drivers on the local machine to build and preview report data.
Report Builder 3.0 still seems to be a 32-bit application (as of 6/3/2016), so you only need to install 32-bit ODAC package.
I've inherited an SQL Server 2008 R2 environment running on Windows Server 2003. I do not know if it was upgraded from SQL Server 2005 or if it was a freshly built out system. Due to issues with not being able to virutalize the physical server, it was decided to build a new, identical environment on a virtual server an migrate the databases and such to the new virtual server. We did decide to make one upgrade and that was to put Windows Server 2012 on the new server. We kept the instance name and server name the same (these were modified after we took the old physical server offline). I kept the file paths and folder names the same as well on the new server. I migrated the SSIS packages from the old server to the new server using the Export option in Integration Services (right click on the package>Export Package). The packages were stored in MSDB on the old server. I copied the config files from the old server to the new server and kept them in the same file location as they were stored on the old server. Ok, so here's my problem. When I started all of the SQL Agent jobs, several of the ones that used SSIS packages failed. After researching the issue, I
discovered it was due to the SQL provider string (Provider=SQLNCLI) was set to Provider=SQLNCLI.1, which is for SQL Server 2005. Once I changed this to Provider=SQLNCLI10, all was good. A caveat to this is that other packages that are using Provider=SQLNCLI.1 and are working just fine. The question that is eating at me is this, why were these packages running successfully on the old server which was running the same version of SQL Server when SQLNCLI.1 is supposed to be a setting used in SQL 2005 AND why are some packages working successfully still using SQLNCLI.1 and other had to be changed??
the execute of some packages depends by the structure of this file.
the are some task or some expression or some parameters that have been redefined in the new releases.
I have a question regarding to SSIS. I designed a package and it worked fine when I executed in my local machine. I used to extract the data from Teradata and load into SQL SERVER 2008. Everything was fine but I'm looking for how to execute the package without my local machine. I mean how to configure and set up the odbc in the SSIS server machine, not my local machine.
Thank you,
Paul
You'll need to make sure you've installed SQL Server Integration Services on the box; then there's a number of ways to go about running it. From there, I prefer to connect to Integration Services from the Object Explorer in SSMS and import packages, using the "SQL Server" as the Package Location. Once the Integration Services on the box has an entry for the package, you'll be able to run it with the agent by specifying a step type of "SQL Server Integration Services Package." I don't think you will need to set up the ODBC on the server itself if you have it configured correctly in your package, but if you do that should be no different than the way you have it set up on your own box.
I am creating my first SSIS package using Business Intelligence in Visual Studio 2012. I am adding the contents of an Excel sheet to an local VS database. In the Destination Assistant I am asked Destination Type = SQL Server, New: Provider - I see no .NET Framework option. The result seems to be that I am then unable to select my server and therefore databases.
Am I just missing the point?
I would recommend that you investigate the destination server and verify that you have the providers installed on that system. Typically these are installed at the time that SQL server is installed, but is possible via custom installation to specify the providers that are installed. It may be necessary for you to install any providers needed. A second option would be to point to a database that you know that you can connect to, say a localhost sandbox or other tried database. That would help you to determine if it's server side or client installation issues.