We are using Quest Geo Solution's Grid InQuest DLL (GIQ60.DLL) within an SQL Server Integration Services (SSIS) package. We have managed to use this without problems locally (32bit) by using tlbimp to create a .NET wrapper (interop). However, when this moved to our integration server this does not work as the server is 64bit.
The GIQ60.DLL is a 16bit DLL and the vendor has confirmed that they no longer actively support this. If we run the 32bit version of DTEXEC on the server , the package runs without problems. Is there a trick/way to convert the .NET wrapper to enable this to work SQL Server Integration Services (64bit install).
Alternatively , we need a replacement free 32bit .net library that will convert OS grid (Easting /Northings) into geospatial longitude/latitude for both UK and Ireland (they use different grid systems) then that would be a viable solution.
The only other solution i can think of is to create a windows service (32bit) that hosts your component and exposes it as WCF or Remoting end point. Then use script task in SSIS to access it. This way you can run your package in 64bit DTEXEC and your component in 32bit process.
HTH
In one environment I support, there is an SSIS package that relies on a certain version of a connection to Lotus Notes. That dll is a 32 bit dll and it doesn't work when executing in SSIS on the 64Bit production server.
We simple execute the SSIS package with a command prompt call to the 32Bit version of DTEXEC. That works fine.
You might try that to avoid having to maintain two different versions of code?
Related
I had to introduce SSIS into my work with SQL Server due to several requirements of the business, as I could not implement changes using other means readily available in standard installation of SQL Server and SSMS.
Up until the SSIS requirement everything was working fine: SSMS hummed nicely, had VS2010 shell for deploying SSRS reports directly to the server and to be able to maintain my reports better than using Report Builder. But it was insufficient for several projects, so SSIS was chosen to deal with that deficiency.
Everything works fine up to the moment of deploying the package. Develop, test and build - package works like a charm. But deployed package just would not work. Troubleshooting pointed to 32/64 bit issue and only after an option "32-bit runtime" checked in advanced configuration in Server Agent job properties. How is that possible when the everything I installed and used is 64-bit? Obviously, that presents additional issues (ODBC drivers, other applications all need 32 bit versions) and resolving those is not as obvious as Microsoft think it is, if it's possible at all.
And then, following logic: how can I set up truly end-to-end 64-bit environment with Microsoft Stack?
To quote my point from the comments:
Likely, the reason, is because you only have 32bit drivers for
something you are using, and thus when using the package, you have to
run in 32bit mode. A "great" example of this is the ACE Drivers. When
in SSDT, the application is 32bit, so has to use the 32 drivers. If
your SQL Server also, only has the 32 bit drivers installed (not
the 64 bit) then, again, you have to use the 32bit run-time option.
It's all about what drivers you are using. If you don't have 64bit
drivers for what you're doing, but have 32bit ones, you have run in
32bit (and vice versa).
Couple of bits emphasised.
I run Visual Studio 2012 and I'm new to SSIS. I attempted to install SSDT-BI (June 2013 version) in order to research SSIS, but I was unable to complete the install with my default instance because the architectures don't match--my server is x64 while the installer is x86. There doesn't appear to be an x64 version of the installer.
Does SSDT-BI not support x64 databases?
SQL Server Integration Services, SSIS, covers a whole lot of territory. I'll discuss what's relevant to this question of 32 vs 64 bit-ness.
Installation
As you discovered, the installer is stupid but you typically only need to use it once or twice in a machine's lifetime. I'm ok with this as I'd rather them spend development dollars are the product and not the packaging.
Following SO best practice, the important piece from the externally referenced site is
If you’re running an x64-based SQL instance (64-bit), make sure to select “New Instance” on the Installation Type page, and NOT “Add features to an existing instance”.
Package
An SSIS package is a deliverable unit of work. It is an file with a .dtsx and internally is a bunch of XML.
Development
Typically, development of SSIS packages is completed by using Visual Studio. Whether you call it BIDS, SSDT or just Visual Studio, it's the same thing. There are registered templates for SSIS as well as all the toolbox entries that get put onto a machine during installation. That stuff supports the design time aspect. Visual Studio itself is still a 32 bit executable. Therefore, when you are creating packages using Visual Studio, the editor you are using to create a package is a 32 bit entity. Unless you are creating a multi-gig package, this shouldn't be an issue.
And one might argue that if you get a multi-GB package that even if XML is a bloated storage mechanism, you are "doing it wrong" ;)
On a final note, development of packages is not constrained to Visual Studio. There is a paid-for product, Mist, that uses Biml (a domain specific language that describes BI objects) to generate SSIS packages. Looking at your SO history, you look like you have some PowerShell chops, you can use PowerShell to modify SSIS packages or flat out create them. There the EzAPI to help with the COM side of generating packages.
Execution
The execution of a package can be from a 32 or 64 bit executable. See How to execute dtsx packages through command line By default, the packages will execute in 64 bit mode from Visual Studio. The design time is 32 bit but run time is 64 bit. This always makes for great entertainment when folks use 32 bit drivers (Excel/Jet/ACE) and the packages design just fine but blow up when they run. The other gotcha of 32/64 driver is the creation of DSNs as there are 2 different DSN "spaces" See 32-bit informix drivers in 64-bit windows server 2008 are unavailable
In 2012, if you use the Project Deployment Model, the packages are stored in the SSISDB catalog. SQL Server only comes in 64 bit flavors but again you can call the 32 bit runtime for SSIS from the catalog by specifying the appropriate Parameter.
If you're using x64 bit SQL Server, make sure select "new instance" on "Installation Type" page in install wizard. check out http://picnicerror.net/development/sql-server/installing-sql-server-data-tools-business-intelligence-for-visual-studio-2013-03-13/
Recently I had to install SSDT BI for a sql 2014 instance. The download available msdn https://www.microsoft.com/en-us/download/details.aspx?id=42313 says its supported for both 32-bit (x86) & 64-bit (x64) architecture. If we install SSDT-BI as an add on feature to an existing sql instance the installation fails with error:
Rule evaluation message: The CPU architecture of installing feature(s) is different than the instance specified. To continue, add features to this instance with the same architecture.
I referred this link https://danieladeniji.wordpress.com/tag/the-cpu-architecture-of-installation-features-is-different-than-the-instance-specified-to-continue-add-features-to-this-instance-with-the-same-architecture/
to work around this issue.
Installing SSDT-BI as as new instance completed without any errors.
Hey, I've just finished writing a VB.NET application. Now I want to package the executable and the database ofcourse into a single installer file. I tried using QSetup, InstallShield to make SQL Server embedded into the setup file, and finally after hours of try&fail I have no idea. Anyone?
You can do a rightmouse on the properties of your Visual Studio Setup Project, and then there is this button 'Prerequisites'. There you can tick 'SQL Server Express ...' Or the 'SQL Server Compact 3.5'
link to image
You're probably best off just to set the connection file directly to the mdf, and attach it when the program is run. This is easier as it doesn't require a custom setup script to install the database to the database directory itself.
Note: Consider using the Compact Version, it's smaller, people don't like a full blown engine on their computer :)
InstallShield has a concept called Setup Prerequisites where you can teach it how to install additional packages along with your own. In older versions this would happen before calling your MSI. In newer versions you can have a "Feature" prerequisite where the prereq can associated to a feature and only installed if that feature is selected to be installed and after it's been selected but still before the main activity of your MSI occurs during the install execute sequence.
InstallShield also has a pattern for executing SQL scripts against your database instance so that you can then load your database into your newly installed instance.
All of this is quite powerful but it does take a bit of digging to learn.
As far as I know, anything but the SQL Server Compact Edition (SQL Server CE) cannot be embedded into your setup, really. Microsoft doesn't want that - you need to have SQL Server Express installed separately - any other edition can't even be shipped with your software (the client must have a license and installation separately).
You can indeed distribute SQL server with your custom application:
http://msdn.microsoft.com/en-us/library/bb264562(SQL.90).aspx
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.
We have a SSIS 2005 package that is installed on a central server and is called from multiple locations.
This package uses a script task to call a .NET DLL which I wrote in c# and installed into the GAC on the central server.
When I call the SSIS package from that server on which the package is installed everything is fine.
When I call the package from a remote server using SQL Server Agent, the job fails reporting that it cannot find the DLL.
Just to test out what is happening I installed the dll on the remote server and the package succeeded. So it appears that although the package is installed on one machine, when it is called from another using SQL Server agend it actually executes on the calling machine and it is the calling machine that must satisfy all the dependencies.
This package is going to be called from dozens of servers, many of which I do not have control over.
Is there a way in which I can, install, configure, compile, call or otherwise do something to the way this package is built or executed so that it will call the DLL from the GAC on the machine where the package is installed?
Unfortunately, you will need to change your design, since SSIS package storage is just that - storage. Execution always takes place on the machine from which the package is called, and all references are treated as relative to that machine.
One option is to add a task to the SSIS package which copies and registers the DLL in the GAC of the calling machine - but if you do not have control over some of the executing machines, there is no guarantee the executing SQL Agent account will have sufficient rights to register a DLL.
Another solution would be to convert the DLL code into a script task inside the SSIS package. This would mean converting the code from C# to VB, and may be non-trivial depending on the detail of your code.
Without more details of the purpose of the package and the functionality of the DLL it's difficult to evaluate other alternatives, but you could consider whether it would be possible to parameterise the package to enable it always to run from the storage server.