We have a VB application that downloads databases from SQL Server 2005.
We migrated the SQL server version to 2016.
The application has stopped working.
(I was told that we need to install a newer version of the SMO connection libraries on our workstations to connect to the SQL server, so we will have to recompile / test / modify our code with SQL Server 2016 compatible libraries. .)
I installed the following 3 files:
AMO objects (SQL_AS_AMO.msi)SMO Objects (SharedManagementObjects.msi)
SQL CLR Types (SQLSysClrTypes.msi)
From: https://support.jetglobal.com/hc/en-us/articles/219401687-SQL-Analysis-Management-Objects
But I do not know what to do next. What should be changed in the source code of the application? how to call these libraries in my application?
Help me please, I'm bad at VB
Error :
could not load file or assembly MicrosoftSQLserver.SMO,
Version=9.0.242.0 Cuture=neutral, PublicKeyToken=89845dcd8080cc91' or
one of its dependencies. The system cannot find the file specified.
Related
I have a DB project which relies on SQL Server Database tools. I am trying to work on it on a Mac. The rest of the project is in .NET Core so that all works well. The database project throws an error on dotnet restore
/Users/mborozdin/src/ethos/FileRepository/src/FileRepository.Database/FileRepository.Database.sqlproj(63,3): error MSB4019: The imported project "/usr/local/share/dotnet/sdk/2.1.4/Microsoft/VisualStudio/v10.0/SSDT/Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
Is there an alternative to SSDT which seems to be only available on Windows?
When you develop on the Mac,
You will put your SQL Server on the docker or Virtual Machine.
In other to connect, You need SQL Operations Studio for the Mac
Download Link
Is there an alternative to SSDT which seems to be only available on Windows?
The alternative is Azure Data Studio. As for:
SQL Database Projects extension
The SQL Database Projects extension brings project-based database development, well-known in SQL Server Data Tools (SSDT), to the cross-platform Azure Data Studio experience. From this early insiders release you can create, build, and publish a project from scratch or an existing database.
https://github.com/microsoft/azuredatastudio/issues/11105
I have an SSIS package that runs fine from Visual Studio but doesn’t work on the server.
Executing under my security context produces the same results as a proxy account.
It's running a custom assembly
The server is running SQL Server 2016
The server has the shared components installed on a different drive (d:)
There is a script task that needs a licence key
Runs fine locally using Visual Studio 2013 (I edited 64 & 32 bit versions of DtsDebugHost.exe.config)
On the server I installed three dll's to the GAC & placed a copy in Program Files and (x86) \Microsoft SQL Server\130\SDK\Assemblies\
a.dll - MSIL
b.dll - MSIL
kernelx86.dll - X86
One of them wouldn't install to the GAC until I edited the GACUTILs config and put the below line in.
Then I edited the config files for running SSIS packages;
1. DTExec.exe.config - Command line execution
2. DtsDebugHost.exe.config - Visual Studio debugging
3. DtsHost.exe.config - SQL Server agent
Either one of the DLLs isn't being used or the licence key still isn't being picked up.
Any suggestions are appreciated,
Dan
Greets.
I've developed some SSIS packages that I want to load up and execute in C# code. The C# code is deployed on our application machine.
I've referenced the SQLServer.ManagedDTS DLL in my C# project.
I tried gac'ing that DLL on our staging application box, which incidentally also seemed to require gac'ing the SQLServer.DTSRuntimeWrap DLL as well.
The code to execute the package is like so
Runtime.Package package = new Runtime.Application().LoadPackage(ssisPackageFilePath, null);
package.Variables["FilePath"].Value = sourceFilePath;
//Excute Package to insert data from source csv file into a SQL table
Runtime.DTSExecResult results = package.Execute();
When I try to run the process I get the following error
An Integration Services class cannot be found.
Make sure that Integration Services is correctly installed on the computer that is running the application.
Also, make sure that the 64-bit version of Integration Services is installed if you are running a 64-bit application
I figured I should be able to simply gac (Install) the one DLL I used to develop the code that executes an SSIS dtsx package file.
I developed the package in a Visual studio 2008 BIDS project which results in a dtsx file.
I referenced the SqlServer.ManagedDTS DLL in a visual studio 2010 project to execute the dtsx file from code.
Tested and debugged locally with success.
What do I need to do to setup my application box in order for my code to be able to execute an SSIS package?
I'm hoping I'm not limited to only being able to execute packages from code on a box that has an instance of SQL server or IntegrationServices installed; which may mean the need for another license.
Do I need to install Integration Services on my app box?
Yes, you need to install Integration Services to run the package on a server. Just deploying DLLs into GAC won't help in executing a package.
Here is the MSDN link that describes about Running an SSIS Package Programmatically on a Remote Computer.
You need to have at least one server with Integration Services installed to be able to do what the MSDN article describes.
I'm developing a Windows Forms application using Visual Studio 2008 C# that uses an SQL Server Compact 3.5 database on the client. The client will most likely be 32 bit Windows XP or Windows Vista machines. I'm using a standard Windows Installer project that creates an MSI file and setup.exe to install the application on a client machine. I'm new to SQL Server Compact, so I haven't had to distribute a client database like this before now. When I run the setup.exe (on new Windows XP 32 bit with SP2 and Internet Explorer 7) it installs fine, but when I run the application I get this error:
Unable to load DLL 'sqlceme35.dll'. The specified module could not be found
I spent a few hours searching for this error already, but all I could find were issues relating to installing on 64 bit Windows and none relating to normal 32 bit that I'm using.
The install application copies the all the dependent files that it found into the specified install directory, including the System.Data.SqlServerCe.dll file (assembly version 3.5.1.0). The database file is in a directory called 'data' off the application directory, and the connection string for it is
<add name="Tickets.ieOutlet.Properties.Settings.TicketsLocalConnectionString" connectionString="Data Source=|DataDirectory|\data\TicketsLocal.sdf" providerName="Microsoft.SqlServerCe.Client.3.5" />
Some questions I have:
Should the application be able to find the DLL file if it's in the same directory, that is, local to the application, or do I need to install it in the GAC? (If so, can I use the Windows Installer to install a DLL file in the GAC?)
Is there anything else I need to distribute with the application in order to use a SQL Server Compact database?
There are other DLL files also, such as MS interop for exporting data to Excel on the client. Do these need to be installed in the GAC or will locating them in the application directory suffice?
You don't need it to be in the GAC for SQL Server Compact to run, and it will pick them up from the application directory. There are several ways to deploy an SQL Server Compact project. The two main ways are:
Deploying the SQL Server Compact redistributable installer with your project, but this way is painful and also can be unistalled by the end user, or upgraded by Windows updates and breaking your application.
Including the DLL files in your application folder. Depending on the features of SQL Server Compact you are using (replication or whatever), there is a handful of DLL files to deploy in your application folder.
If you have SQL Server Compact installed on your machine, they are most likely located at "C:\Program Files\Microsoft SQL Server Compact Edition\v3.5". They can be added to the project in Visual Studio and then set their project output type to "copy always". And the main reference to System.Data.SqlServerCe that you have in your project references should have copy local set to true.
sqlceca35.dll
sqlcecompact35.dll
sqlceer35en.dll
sqlceoledb35.dll
sqlceqp35.dll
sqlcese35.dll
If you have these all set, then in your installer project all you have to include is the project output of this project and you're good. In my opinion this is the only way to go. It is a simple deployment, of a couple of files and you are in control of what DLL versions your application uses.
I hope that helps.
I had a similar problem, a Visual Studio 2008 Windows application targeting 32-bit Windows XP and Windows Vista that used SQL Server Compact 3.5 SP1 - that then got this error when installed on 64-bit Windows 7:
Unable to load DLL 'sqlceme35.dll'. The specified module could not be found
I was embedding an MSI for SQL Server Compact into the installer for the application.
Following this rather confused discussion on MSDN revealed that I needed to use the 64-bit MSI for SQL Server Compact on 64-bit machines. D'oh! That is, from page Microsoft SQL Server Compact 3.5 Service Pack 1 and Synchronization Services for ADO.NET version 1.0 Service Pack 1 for Windows Desktop I needed SSCERuntime-ENU-x64.msi rather than SSCERuntime-ENU-x86.msi for 64-bit machines.
How to: Deploy a SQL Server Compact Edition Database with an Application should help, at least with your first two questions.
In general, I think you should not install anything in the GAC for a single application.
The following provide a solution to the problem and an explanation also.
Troubleshooting: Can’t load SQL Server Compact DLL
SqlCeException on application's first use of SQL Server Compact
Laxmi Narsimha Rao Oruganti 's blog
I hope this helps.
Ok, I've scoured the web, BOL, various forums and I'm no closer to an answer...hopefully you fine folks can lend a hand...
We've got a dozen or so SQL Servers (some 2k, some 2005) on a network. I'm using SMO objects in a .NET application to get some standard information. My problem appears to boil down to a missing DLL - Microsoft.SqlServer.BatchParser.dll. However, this DLL did not come with the other SQL DLLs (Microsoft.SqlServer.ConnectionInfo.dll, Microsoft.SqlServer.Smo.dll, Microsoft.SqlServer.SmoEnum.dll, Microsoft.SqlServer.SqlEnum.dll, etc...). I also downloaded the SS2005 feature pack from Microsoft's site that includes the SMO objects, but still no luck.
The following code works, unless I uncomment the line that is currently commented, in which case I get the error below:
protected void btnArchive_Click(object sender, EventArgs e)
{
ServerConnection conn = new ServerConnection("my_server");
conn.LoginSecure = false;
conn.Login = "my_login";
conn.Password = "my_password";
Server s = new Server(conn);
Database d = s.Databases["my_database"];
//Table tbl = d.Tables["my_table"];
Response.Write(s.Name + " " + s.Information.RootDirectory + " " + d.CreateDate.ToShortDateString());
conn.Disconnect();
}
Error:
Could not load file or assembly 'Microsoft.SqlServer.BatchParser, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified.
Note, I've also tried this from SSIS using VB.NET, same behavior.
Any thoughts would be appreciated.
Thanks.
I was able to successfully run your code using the 10.* versions of the assemblies "Microsoft.SqlServer.ConnectionInfo", "Microsoft.SqlServer.Management.Sdk.Sfc" and "Microsoft.SqlServer.Smo". Try downloading the 2008 version of the SMO components, maybe it was a bug that they've now fixed.
Are you running a x64 OS on your box? There appear to be problems with BatchParser.dll in 64-bit environments - usually it is recommended to download the SMO x64 Package (SQLServer2005_XMO_x64.msi) from Microsoft.
See information about this here.
I know I'm very late to the party here, but this is still the first result when you google "smo batchparser".
When installing SMO 2014 (12.0.x) some DLLs are only installed to the GAC. To make your app work without having to manually install SMO in the target server, you must copy these DLLs with your app. Here are the paths where I got them from.
C:\Program Files\Microsoft SQL Server\120\SDK\Assemblies\Microsoft.SqlServer.ConnectionInfo.dll
C:\Program Files\Microsoft SQL Server\120\SDK\Assemblies\Microsoft.SqlServer.Management.Sdk.Sfc.dll
C:\Program Files\Microsoft SQL Server\120\SDK\Assemblies\Microsoft.SqlServer.Smo.dll
C:\Program Files\Microsoft SQL Server\120\SDK\Assemblies\Microsoft.SqlServer.SmoExtended.dll
C:\Program Files\Microsoft SQL Server\120\SDK\Assemblies\Microsoft.SqlServer.SqlEnum.dll
C:\Windows\assembly\GAC_64\Microsoft.SqlServer.BatchParser\12.0.0.0__89845dcd8080cc91\Microsoft.SqlServer.BatchParser.dll
C:\Windows\assembly\GAC_MSIL\Microsoft.SqlServer.BatchParserClient\12.0.0.0__89845dcd8080cc91\Microsoft.SqlServer.BatchParserClient.dll
C:\Windows\assembly\GAC_MSIL\Microsoft.SqlServer.SqlClrProvider\12.0.0.0__89845dcd8080cc91\Microsoft.SqlServer.SqlClrProvider.dll
To access the GAC files you will need to disable the windows built-in viewer using the instructions provided by this article.
An excerpt of the article for convenience:
Open the registry editor and add/set the HKLM\Software\Microsoft\Fusion\DisableCacheViewer DWORD value: 1
You need to install following package to solve the problem , I have solved this problem twice with this package hope it may work for everyone too...
Microsoft SQL Server 2005 Management Objects Collection The Management Objects Collection package includes several key elements of the SQL Server 2005 management API, including Analysis Management Objects (AMO), Replication Management Objects (RMO), and SQL Server Management Objects (SMO). Developers and DBAs can use these components to programmatically manage SQL Server 2005.
You can get from Feature Pack for Microsoft SQL Server 2005 - December 2008 from Microsoft site
http://www.microsoft.com/en-us/download/details.aspx?id=11988
But the link location of download page changes every-time if you don't find resource you can download it from my blog too.
I have also provided some tips and resources about this in my blog if you want http://rndp-android.blogspot.com/p/missing-microsoftsqlservermanagementsdk.html
Just so we understand the issue properly, the Microsoft.SqlServer.BatchParser.dll is not installed in the Global Assembly Cache on your development machine? If so, you might want to start with re-installing the .NET Framework (the version of the Framework that you are targeting) to see if that resolves the issue.
You can also try using the .NET Framework Configuration tool to see if the assembly is indeed present in the Global Assembly Cache (GAC). This MSDN Article describes how to use this tool.
(A search of my hard drive did not return the Microsoft.SqlServer.BatchParser.dll assembly even though I can see it using the .NET Framework Configuration tool).
it comes as part of the 2005 or 2008 upgrade advisor.