Thank you in advance for your help on this issue.
Here is the situation:
I have a SSIS package that essentially take data from a excel file ( using a Excel Connection) and upload it to a SQL table through a OLE DB Connection. This package runs completely fine in Visual Studio but I keep having this error once it is deployed on SSMS:
Failed to configure a connection property that has the following path: \Package.Connections[Excel Connection Manager].Properties[ConnectByProxy]. Element "ConnectByProxy" does not exist in collection "Properties".
; at Microsoft.SqlServer.IntegrationServices.Server.ISServerExec.ConnectionParametersManager.ConfigureProperty(String parameterName, Object parameterValue)
at Microsoft.SqlServer.IntegrationServices.Server.ISServerExec.ConnectionParametersManager.ConfigureProperties()
at Microsoft.SqlServer.IntegrationServices.Server.ISServerExec.ProjectOperator.ValidatePackageWithReference(Int64 validationId, Int64 infoId, Int64 projectId, String packageName, Int64 versionId, Nullable`1 referenceId, Project isserverProject, Boolean offlineMode)>
And I have the same error when it comes to the OLE DB ( SQL Server Native Client 11.0) connection.
Both Connections are at the project level and I deploy the hole project in SSMS. I also have the Microsoft.ACE.OLEDB.16.0 provider installed in SSMS.
To fix that error I have made some changes in the project configuration in SSMS like setting the ConnectByPoxy value to TRUE or adding my UserName but still failed. The package is pretty simple, has no parameters, no variables.
Also tried checking the 32 bit runtime..
Sometimes SSIS can throw strange errors when working with deployments to remote servers that you never encounter when executing the package locally. This implies there is likely something wrong with the compatibility of the server's version of SQL Server and your local copy (of SQL Server or Visual Studio). Perhaps verifying the deployed version of SQL Server your remote server uses and comparing it to your local copy would be worthwhile.
If they do match, next I would check the project's target SQL Server version by following the instructions at this site, and ensure it is correct. I would also confirm that the server has access to the directory in which the Excel files are being received, just to be safe.
This article specifically addresses the "ConnectByProxy" element issue you are encountering, and may prove helpful in resolving the issue or at least in giving more insight into possible issues.
Related
I have create a SSIS package to extract data from oracle source and load data into a SQL Server database. It runs successfully when run it on SSIS.
But I'm getting an error when I runs the packages on SQL Server catalog.
Errors shown below
I also changed the execution type into 64 to 32 and try again. But same error occurred.
Kindly give solution for this.
Thanks.
Make sure you change it to 32bit in the package, and in the SQL Agent job if there is one. Also, as you are using ODBC, ensure you're using the 32bit ODBC driver and not the 64bit version - There are two different ODBC Data Source Administrators, one for each.
You could always change the job to OLE DB and see if that works correct just to make sure it's not a network/firewall issue.
Based on the error message, the issue should be related to account permissions.
As per my understanding, the account that log on the SQL Agent job
may doesn’t have permission to access the database server or SSIS
engine uses the design time values of a task until it actually runs a
task when DelayValidation is not set to true.
Note: If user has sysadmin permission doesn't means he has permissions to access the database server in ODBC Connection Manager.
Error message Fix:
Make sure the account in the job step is used to run the package has permissions to access the database server in ODBC Connection Manager. And change the DelayValidation property of your Data Flow Task to true and then re-ran the job.
I have some troubles to automatize a package SSIS with a job SQL Server.
I have to get some data from a DB PostgreSQL to a DB SQL Server. For that, I'm using an ODBC connector (downloaded from http://www.postgresql.org/ftp/odbc/versions/msi/ and added using administrator console odbc in C:\Windows\SysWOW64\odbcad.exe):
driver odbc:
odbcad:
To be able to run the SSIS package, I had to change debugging settings in SSDT to run the package in 32 bits mode :
So far, everything works fine, but when I'm trying to automatize it with a SQL Server job, the job fails. Yet, I specified to my job to run in 32 bits mode too:
Below, the errors I got (sorry it's french):
The most meaningful error is
failed to call method acquireconnection to connection manager "PostgreSQL". Error code : 0xC0014009
I'm stuck & every related posts I found are solved using the checkbox "32 bits mode" checked on the job.
Thank's to M.Ali, I found the solution.
I just needed to add the DSN connection under System because the job SQL Agent is launch with another account than my current user.
I was working on an ASP.NET MVC5 application and pushed it to git. Someone else cloned the project to their computer.
When they try to run the app it works up until there is a database call. They get the error message:
System.Data.SqlClient.SqlException: 'A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)'
In the Server Explorer we can see that the connection is closed. We also see no tables at all, like as if there was no database.
Does anyone know how we can approach this? I'd think that the connection string remains the same on each machine? The database was created code first, do we somehow have to recreate it? If so, how?
Thanks for your suggestions!
The connection string should be the same.
You should first disable Windows Firewall and antivirus programs (and similars), if they're present, and test again.
You should try a connection via another database client too, just to check if you are blocked someway.
If these attempts doesn't solve the problem, you can recreate the database for test pourposes, if you will. For Entity Framework, for example, search "migrations" term in Google.
The error is relevant. Obviously, from the computer hosting the cloned solution, the SQL server is not reachable.
If, in development, you used a local SQL Server (like SQL Express or Local DB), you must verify that on the computer hosting the clone solution you have the same setup. If you used a remote server, you must check that the server is available to the computer hosting the cloned solution.
In both cases, you can use Server Explorer to verify the db connection and access.
Unfortunately, there is no satisfying answer.
At first, we reinstalled Microsoft SQL Server. That alone did not help.
We did change the autentication from Windows Authentication to SQL, because the person working on that workstation still had the account details from the previous owner.
That alone did make the test connection successful. But then, we got another error when doing the "Update-Database" command in VS, which we solved by deleting a rogue migration that was there for some reason unknown.
Now it works - sorry for not offering a more concise solution.
Aware that this topic has been raised many times here (I have gone through the posts), but none of the suggestion on the posts has resolved my issue.
When I attempt to create a linked server to the oracle database from SQL Server Management Studio, I get the error:
Cannot create an instance of OLE DB Provider 'OraOLEDB.Oracle' for
linker server ''. (Microsoft SQL Server, Error: 7302)
My understanding of this error is that the Oracle provider is not installed correctly or not at all.
To check this I ran 'ODBC Data Source Administrator (64-bit) and attempted to add the provider (which was not available).
To resolve this I fully installed Oracle 10g Client as an admin and restarted the server. I added the new oracle bin folder to the environment %PATH% as well as %TNS_ADMIN% to point to the tnsnames.ora file.
I have run 'tnsping' using the value specified in the tnsname.ora file and it is able to connect.
I have exhausted my ideas to get the oracle provider recognised by the ODBC 64 bit connector.
Does anyone have any idea that could resolve this issue?
Thank you for any help.
The solution was to follow the steps suggested by Dmitry. However, make sure you carry out the following step:
C:\Users\dbrowne\Downloads\ODAC121010Xcopy_x64>.\install.bat oledb
c:\oracle\odac64 odac64 true
as an admin!
After resolving issues with RIA installation here, I'm still getting this following error. Not much special - I tried to create a new screen based off of data sources from an existing database in a full SQL 2005 instance
An error occurred while establishing a
connection to SQL Server instance
'.\SQLEXPRESS'. A network-related or
instance-specific error occurred while
establishing a connection to SQL
Server. The server was not found or
was not accessible. Verify that the
instance name is correct and that SQL
Server is configured to allow remote
connections. (provider: SQL Network
Interfaces, error: 26 - Error Locating
Server/Instance Specified)
I've tried to correct the connection string in the, I guess, autogen'd config file. Even though Visual Studio doesn't seem to think that the file is overwritten on rebuild, the error continues to appear.
How can I use LightSwitch with full SQL 2005 rather than SQL Express?
It seems when working Locally, LightSwitch uses SQL Server Express. It puts it's Membership, Roles, and other authentication information here. I don't know any way to get around this locally, but when you go to "Publish" your project, you're given the ability to use a different database/server. You can also use whatever server/database you'd like for your data sources as well.
Hopefully, before V1, they'll allow you to change that. But I haven't found a way yet, without the config being overwritten constantly.
You can't use it with non Express version during development when you want to use LightSwitch to create your data model. If you deploy your project, as mentioned, you can use the created database with full version and change the connection string.
Although I would be cautious using SQL Server 2005 because LightSwitch is using datetime2 which is new in 2008. (maybe some more 2008 specifics as well)
http://lajak.wordpress.com/2011/10/04/lightswitch-change-default-database-instance/
Here, they are telling how to change instance name both in project level and global level.