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.
Related
I am trying to run a flatfile SSIS package via .Net code using the Microsoft.SqlServer.Dts.Runtime DLL version 14.0.0.0.
Upon executing I get "To run a SSIS package outside of SQL Server Data Tools you must install Standard edition of Integration Services or higher"
I have SSIS for Visual studio 2017 installed, along with with SQL server 2017 both have the SSIS extension installed.
There are a number of questions relating to this error when trying to run via the DTExe directly; but haven't found any questions regarding troubleshooting the Dts.Runtime DLL.
I presume that the DLL calls DTExe, but I don't know to tell which DTExe it will call. Using the "wrong" DTExe is the solution to many other questions regarding this error.
Whether you're using the managed object model or using the tooling, both are going to check to see whether the SSIS Service is installed on the machine. It is a requirement of licensing to run an SSIS package that the server running the package be a licensed SQL Server instance. So, the application you've written hopefully is targeted for running on a machine that already has a SQL Server server standard license or above.
For development, that runs you about 50 bucks last I checked. For production, we're talking tens to hundreds of thousands of dollars.
For completeness, SQL Server 2005 and 2008 SSIS packages would run on machines that had the data tooling installed (then called the Business Intelligence Design Studio, or BIDS) because the only way to acquire the installation media was to have the ISO images of SQL Server, Developer edition or above.
With 2012, you could now download the SQL Server Data Tools, SSDT without having the SQL Server product but you lost the ability to run packages outside of the Visual Studio debugger - which is a shame as the debugger can severely impact the throughput of a package.
If you check the licensing requirements - scaling out SSIS to different machines is not included in the Enterprise edition license.
SQL Server does not need SSDT installed to run an SSIS package. The option for installing the tools to run and interactive with it (dtutil, dtexec, ssisdeploymentwizard) .. might exist or not depending on version. But that's running packages. Development is where SSDT comes into play. SSDT designs and runs packages within the context of development (Visual Studio debugger). Anything else is going to get blocked by that licensing check.
I've been able to successfully create an ssis package (.dtsx) file using the SSMS 'import data' option and the VS 2017 SSIS toolbox (SQL Server 2017). The package itself works and it reads a csv file and loads it into a database table. Simple. This is on windows 10.
I'm trying to run these packages on Win Server 2012 R2 (Azure VM) command line and it won't work (it does work from VS 2017) because the dtexec.exe files are all 32 bit. For the life of me I cannot get a 64 bit dtexec.exe file installed.
I've tried
the same procedure on windows 10 and it works. I create the package and then I can run it via dtexec /f "path to .dtsx"
I've tried to set the run time to 32 bit per (
SSIS 64 bit vs 32 bit)
But this is not an option in either the SSMS import data tool or VS 2017 SSIS Toolbox settings/properties.
I've come across this page
(https://www.sqlservercentral.com/articles/how-to-execute-an-ssis-package-from-the-command-line-or-a-batch-file)
But I'm not sure that turning this package into a 'package deployment model' is the way to go.
I've tried copying the 64bit dtexec and related files to the Win 2012 R2 machine but the dll and code is not registered.
When I try to install SSMS or SQL Express on the server I don't get options for customizing the install.
I've confirmed that the server is 64-bit.
I've tried an azure logic app but I simply don't like it that way.
These are some of the errors I'm seeing
Code: 0xC001700A
Description: The version number in the package is not valid. The
version number cannot be greater than current version number.
Could not create DTS.Application because of error 0x80040154
I would like to keep things simple and create an ssis package that can then be run at the server via a command line script that is scheduled. Why in the world is this so hard to set up on an Azure VM running Windows Server 2012 R2?
Below are a couple of more resources I've stumbled upon. Looks to me that the VS 2017 SSIS toolbox way of doing this is what MS wants people to use. How could it be that they make it so easy to create the workflow and store that into a package (the dataflow works on the Win 2012 R2 server inside of VS 2017) but when it comes time to roll it out and automate it everything falls apart? I must be missing something. Any help would be useful. How the hell do I tell VS 2017 to create a 32-bit compliant version of this package?
https://learn.microsoft.com/en-us/sql/ssdt/download-sql-server-data-tools-ssdt?view=sql-server-2017
https://learn.microsoft.com/en-us/sql/integration-services/lesson-1-7-adding-and-configuring-the-ole-db-destination?view=sql-server-2017
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 am using Visual Studio 2012 with SQL Server 2012 Data Tools installed. For some unexplained reason, my workstation will only run my SSIS code in 32 bit mode. Here is a dummy data flow I built for testing purposes:
Here are my settings:
It only runs DTSDebugHost.exe *32.
I am at my wits end trying to figure this one out. What do I do to figure out why it is not running just DTSDebugHost.exe (the 64 bit version)?
This happens because VS 2012 is checking to see if VS 2010 ULTIMATE is installed. It just looks for a registry entry.
Solution:
Open Regedit
Browse to
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\vs\Servicing\11.0\
Create a Key called premium
Create a Key called ultimate
Browse to
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\vs\Servicing\10.0\
Create a Key called premium
Create a Key called ultimate
Restart VS 2012.
Now it should work in 64-bit mode when you debug.
Ran into an almost identical problem and solution with SQL Server 2014 Enterprise, after installing SSDT-BI for VS 2013.
On a side note, I tried using the 64-bit debug host in SSDT-BI VS 2013 on two separate installs. One
where a full instance of SQL Server 2014 Enterprise was already
installed (with 64-bit debug host installed and verified) and another
where no previous SQL Server components had been installed at all. I
wanted to ensure that the "no debug with 64-bit runtime" issue was not
simply due to a missing 64-bit debug host or that the 64-bit host was
not installed as part of SSDT-BI for VS 2013 (It is not. It's part of
the full SQL Server itself, Integration Services (Shared Feature).
Per this thread on Social MSDN, adding the following registry key was what got the 64-bit debug host working for me:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\vs\Servicing\11.0\professional
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