I'm getting the following error when trying to initialise the SMO objects in my application:
Microsoft.SqlServer.Management.Trace.SqlTraceException: Failed to initialize object as reader. ---> System.IO.FileNotFoundException: Could not load file or assembly 'file:///c:\Program Files\Microsoft SQL Server\100\Tools\Binn\pfclnt.dll' or one of its dependencies. The system cannot find the file specified.
This file is indeed missing from that location.
Any ideas why and where I can go about getting it?
I'm running:
SqlServer 2005
ManagementStudio 9.00.4035.00
WinServer 2003 SP2
I experienced the same problem which was solved by switching over to x86 (from AnyCPU). It seems that the assembly is only available in 32 bit mode.
Next problem was "Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information."
This was solved by adding the useLegacyV2RuntimeActivationPolicy attribute in my app.config. I already hade the supportedRuntime node, and can't say if it's necessary for the solution to work.
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0" />
</startup>
</configuration>
You could try to reinstall SQL Server Management Studio or update to the latest service pack to fix this kind of issue.
If it is not working, you could also upgrade to SQL Server Management Studio 2008 since it is backward compatible with SQL Server 2005.
SQL Server 2005 SP4
SQL Server Management Studio 2008 Express (also works with Standard and Enterprise editions)
Related
I have a few SSIS packages, developed in SQL Server 2008. Those packages have ActiveX Script Task. When I try to open those packages in VS 2017, it throws an error, saying ActiveX task is deprecated. Converting those task to Script Task would be really time consuming.
Is there a way to execute those packages in SQL Server Agent? We use SQL Server 2016 Standard edition.
I tried executing from the file system, but it also throws an error:
The "Microsoft.SqlServer.Dts.Tasks.ActiveXScriptTask.ActiveXScriptTask, Microsoft.SqlServer.ActiveXScriptTask, Version=12.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91" task has been deprecated and cannot be used with this version of Integration Services.
I don't really need for now to upgrade those packages, I can still use Business Intelligence 2008 to maintain them. I just need them to run on the SQL Server 2016 instance.
Thanks for your time and help
Sadly, SQL Server is telling you the answer in the error message quite simply.
It is Deprecated and cannot be used.
I'm using Visual Studio 2015 to create a simple SSIS package. The data source is a DB2 database, and I'm using an ODBC driver on my workstation to connect to DB2. The target is SQL Server 2014.
The package runs fine locally, but whenever I run it on the server, I'm having trouble with the ODBC data source. The driver on the server is the exact same one with the exact same name as the one on my workstation.
To get the package into the server, I've imported the dtsx file into SSIS in Stored Packages. I've also tried to deploy the project to the Integration Service Catalog, but I get one of these failures related to the ODBC source when doing so --
The version of ODBC File Source, clsid {xxx} is not compatible with this version of the Data Flow.
The component is missing, not registered, not upgradeable, or missing required interfaces. The contact information for this component is "ODBC Source;Connector for Open Database Connectivity (ODBC) by Attunity; Attunity Ltd.; All Rights Reserved; http://www.attunity.com
I've also tried using a file based ODBC source instead of a system one with that file in a shared folder on the server. Again, it runs fine in VS but not on the server.
I've looked at the dtsx file (xml based) and I suspect that there is a conflict with the DTSID for the ODBC driver. I'm not sure how that works but it seems like that ID would be unique for each computer and that SSIS is getting is trying to use the workstation's DTSID on the server.
I'm a bit new to SSIS and Visual Studio so I'm hoping I'm assuming there is a straightforward way to run packages developed on a workstation at the server without these hangups. I just can't find anything specific to this problem anywhere.
We do not have VS or SSDT installed on the server.
EDIT: I added a second sentence in the 2nd error message above. It refers a connector provided by Attunity, which is something I don't understand. The ODBC driver installed on the system is from Data Direct. The CLSID returned in the error message is also associated with an Attunity connector in the server's registry.
There are no ODBC drivers from Attunity showing up in either of the ODBC managers, so it's possible that these are somehow part of a default install or were installed when our server used to have SSDT and VS installed directly on it and were never uninstalled. Or, something else?
I have resolved this issue by changing the Deployment Target Version of Integration Services project in VS in my case from SQL Server 2017 to SQL Server 2016 (the target SQL version). Hope this helps. Old quesition, but came up first in google when I tried to solve my problem.
In my case this issue was caused by deploying an SSIS project to a 2016 server using SQL Mgmt Studio 2017. Once I redeployed using SSMS 2016, it resolved the error.
VS or SSDT by default uses 32-bit drivers, so check there is option when you execute for 32-bit. Or install both 32-bit and 64-bit driver and create ODBC with same name.
This is what i do usually for ODBC connections in SSIS -- create connection in both 32-bit and 64-bit.
So create one with
C:\Windows\SysWOW64\odbcad32.exe (32-bit)
and one with
C:\Windows\System32\odbcad32.exe (64-bit).
I had this same problem when executing my package in SQL Server Agent. I resolved it by turning on the Execution Options "Use 32 Bit Runtime" flag in the agent step. Drove me nuts for a few days, hope this helps.
check the version of your solution vs the SQL version of where you are deploying. I had this issue and matching up versions fixed the problem. My solution was 2017 but the SQL box was 2016. I had to change the solution to 2016. cheers!
In my situation I was having this error and I switched to using the 32-bit version. My initial test worked, then I redeployed using a the project I was working with and I got this error again, even though I had switched Execution Options "Use 32 Bit Runtime" flag.
It ended up that I was having problems with my ODBC Data Source. I was using IBM Informix driver and it was having an issue with the chosen locale. I changed it to use the server's specific local and tested its connection. That then worked and my SSIS package worked on the server.
In another situation with this same Informix driver, I had the database name, slightly incorrect and that gave me this same error.
I am trying to attach database file in SQL Server. I am getting the below error. The same error I am getting while trying to attach database from Visual Studio. I am using Visual Studio 2013 and SQL Server 2014 Management Studio.
My connection string:
<add name="Sample"
connectionString="Data Source=(LocalDB)\MSSQLLocalDB;AttachDbFilename=C:\Users\M\Desktop\SampleApplication1\App_Data\Sample.mdf;Initial Catalog=SampleDBContext;Integrated Security=True;"
providerName="System.Data.SqlClient"/>
Error:
The database 'sample' cannot be opened because it is version 851. This server supports version 782 and earlier. A downgrade path is not supported. Could not open new database 'Sample'. CREATE DATABASE is aborted.
and here is the default SQL Server instance is set in Visual Studio.
You CANNOT do this - you cannot attach/detach or backup/restore a database from a newer version of SQL Server down to an older version - the internal file structures are just too different to support backwards compatibility. Obviously, your database is from a SQL Server 2016 pre-release (internal version: 852) while the engine you're trying to attach it to is SQL Server 2014 (internal version: 782).
You can either get around this problem by
using the same version of SQL Server on all your machines - then you can easily backup/restore databases between instances
otherwise you can create the database scripts for both structure (tables, view, stored procedures etc.) and for contents (the actual data contained in the tables) either in SQL Server Management Studio (Tasks > Generate Scripts) or using a third-party tool
or you can use a third-party tool like Red-Gate's SQL Compare and SQL Data Compare to do "diffing" between your source and target, generate update scripts from those differences, and then execute those scripts on the target platform; this works across different SQL Server versions.
I was having this issue while following an old Pluralsight MVC4 tutorial.
The course was asking me to use v11.0, but I was running a 2015 version. I opened up the SQL Server Object Explorer and looked at the different versions of LocalDB, and grabbed the name of the one that had my database in it (right-click "Rename").
I then pasted the name in the Add Connection window, under Server Name. Clicked Refresh, and voila, there it was. Hope this helps anyone out there.
This Microsoft link may resolve your problem if you are still running Visual Studio 2015 and seeing this error - the answer above is part of the answer. (megamaiku) The "generate scripts" answer from Mark_S will work assuming you have no trouble mounting/accessing the database. If I recall the SQL Compare is rather expensive but that is a great solution, again, assuming you can mount the database created by your Visual Studio application.
A similar issue arises with Visual Studio 2017 and SQL Server 2017 except you see 852/856 as the version problem.
After moving the database, change your web.config connectionString to match your server; (localdb)\MSSQLLocalDB or possibly localhost depending on what you are running
(SQL 2016/2017/2019).
<add name="DefaultConnection"
connectionString="Data Source=(localdb)\MSSQLLocalDB;myDB.mdf;Initial Catalog=MyDBName;Integrated Security=True"
providerName="System.Data.SqlClient"/>
OR
<add name="DefaultConnection"
connectionString="Data Source=localhost;myDB.mdf;Initial Catalog=MyDBName;Integrated Security=True"
providerName="System.Data.SqlClient"/>
An old article explains how to pull the pieces from the database one at a time and if you're lucky and it still works (it did a decade ago - separate and then put the parts back together), you may be able to get what you need - a newer version restored to an older version. I am unable to find a reference to the trick but rather than scripting your entire database, there is a way to restore down by restoring the header (restore headeronly), then once the header is in place on your server and the permissions and so on are matching, you can restore that database from the newer backup.
However, the generate script is less convoluted and more popular.
I have SQL Server 2014 installed. When I'm attempting to create a data connection within Visual Studio Express 2013 for Windows Desktop it's giving me the below error.
Unable to add data connection. Could not load file or assembly. Microsoft.SqlServer.Management.Sdk.Sfc, Version=11.0.0.0, Culture=neutral, PublicKeyToken=[key] or one of its .dependancies. The system cannot find the file specified.
I have downloaded and installed both the .msi files advised in this answer.
Although the answer states that with SQL Server 2014 you should receive the error message stating Version=12.0.0.0, however I'm receiving the error message showing Version=11.0.0.0. Should I maybe download and install the ENU\x64\SharedManagementObjects.msi for SQL Server 2012?
Checking C:\Windows\assembly shows that Microsoft.SqlServer.Management.Sdk.Sfc is installed as version 12.0.0.0.
I downloaded ENU\x64\SharedManagementObjects.msi for SQL Server 2012.
It would appear that when using Visual Studio 2013, and SQL Server 2014, it requires version 11.0.0.0 of Microsoft.SqlServer.Management.Sdk.Sfc.
For both types (32 bit and 64 bit), this works:
Open URL http://www.microsoft.com/en-us/download/details.aspx?id=35580
Download ENU\x86\SQLSysClrTypes.msi
Download ENU\x86\SharedManagementObjects.msi
Install ENU\x86\SQLSysClrTypes.msi
Install ENU\x86\SharedManagementObjects.msi
Restart your Visual Studio and now Everything will work smooth.
See here.
I am using Visual Studio 2013 with SQL Server 2012.
When I try to add a SQL Server project (*.sqlproj) to my solution, I receive the following error:
Could not load file or assembly
'Microsoft.Data.Tools.Schema.Utilities.Sql.12, Version=12.0.0.0,
Culture=neutral, PublicKeyToken=etc...' or or one of its
dependencies. The system cannot find the file specified.
According to Microsoft, SQL Server Data Tools comes installed as part of the default installation with Visual Studio 2013.
Anyone else had this problem?
I've the same problem and found some decision possible it is suitable : http://sdksdotnetfunda.blogspot.com/2012/08/could-not-load-file-or-assembly.html