I have a server that I am working on that is using Windows 2008 SP2 Enterprise and I have found that the installed version of Robocopy is missing the MT (multithread) switch.
Since I'm working with enterprise hardware, having multiple threads can really help my performance so I'd prefer not to have to remove the switch from the copy operation that I am attempting.
What I don't understand is why the installed version is missing this switch since this is a 2008 windows instance. Was the MT switch introduced in 2008R2?
Is there any way I can safely update this version of robocopy (such as copying the executable from one of my other environments)?
To provide just a little background for contextual purposes this command is being issued as part of an automated backup process developed in SSIS. This process executes normally in other environments, so I'm trying to establish a means of upgrading all the older versions with a more recent version of robocopy to maintain functionality. Otherwise I will have to contextually disable the inclusion of the switch which is a pain.
According to the documentation on Technet, the /MT parameter applies to Server 2008 R2 but not Server 2008. I'm not sure if this is due to just the version of the robocopy executable or some other restriction.
What is the File Version of your robocopy.exe, as shown in the file properties?
You might try to pull the newest version of Robocopy (6.1.7601) out of KB2639043 and see if that works for you. Though, information I found on this thread suggests that newer versions of Robocopy don't work at all on Server 2008.
Related
We have SSMS 2012 installed on several servers (mix of physical and virtual hardwares) with the 64-bit DTExec.exe Version 11.0.2100.60 that we use to run SSIS packages. The SSIS packages are stored in a Microsoft SQL Server 2016 on another physical server.
On one of the SSMS 2012 servers, I installed SQL Server Data Tools for VS2017. Since then, one of our SSIS packages would not run to completion. It aborts about halfway, specifically, when it is about to run (or already running?) the script component of the package. When it aborts, %ERRORLEVEL% is set to a high negative number (-1073741819). I make sure the 64-bit DTExec.exe Version 11.0.2100.60 is the one being used to run the package by putting its path, C:\Program Files\Microsoft SQL Server\110\DTS\Binn, ahead of any other versions’ paths in the PATH environment variable. (It also shows “64-bit” and the version number inside the DOS box where the package is running.)
If I run the same failing package from another SSMS 2012 server using its local copy of the same 64-bit DTExec.exe 11.0.2100.60, the package runs fine. So I suspect the 64-bit DTExec.exe 11.0.2100.60 on the server where I installed SSDT 2017 somehow got “corrupted” (?).
I have uninstalled SSDT 2017 but still the package fails.
Curiously, if I use the 32-bit version instead of DTExec.exe with the same version 11.0.2100.60, the package runs fine. So all the more reason for me to suspect that the 64-bit DTExec.exe version was “corrupted”.
Is there any way to “repair” the 64-bit DTExec.exe Version 11.0.2100.60 to restore it to its former glory? I realize we can just use the 32-bit version but we’d like to use the same version of DTExec.exe across all our SSMS 2012 servers so they all share identical PATH environment variables, .BAT files, etc..
Any leads appreciated – thank you!
EDIT: I'd also like to add that before failing, a DOS window pops up then very quickly closes. The DOS window seems blank but it could be that it just closes very fast for me to see. On other SSMS servers where the packages runs to completion, no DOS window pops up.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Exception 0x80040154 generated while executing a simple ssis package in MS SQL 2008R2 enviornment
I am trying to execute a simple SSIS package on MS SQL 2008 R2.
I am reading a flat source file, sorting the data based on the ID and write the results in a new flat source file destination.
But when I execute, I get following exception:
TITLE: Microsoft Visual Studio
Failed to start project
ADDITIONAL INFORMATION:
Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)) (Microsoft.DataTransformationServices.VsIntegration)
How do I proceed from here?
A lot of forums ask to reinstall MS SQL environment but I am not sure if this is the only way to get rid of the exception.
Any better or alternate ways to get rid of this exception?
Thanks.
Try this:
The most common reason for this error message is running a 32 bit dtExec on a 64-bit machine. This post will explain it properly - Quick Reference SSIS in 32- and 64-bits.
Edit: Cached Google link of the article:
http://webcache.googleusercontent.com/search?q=cache:FQN0QKQCleEJ:toddmcdermid.blogspot.com/2009/10/quick-reference-ssis-in-32-and-64-bits.html+&cd=1&hl=en&ct=clnk&gl=au#!http://toddmcdermid.blogspot.com/2009/10/quick-reference-ssis-in-32-and-64-bits.html
There are quite a few misconceptions flying about out there regarding SQL Server Integration Services and 64 bitness. I've had to set more than a few people on the right path in the forums - mostly on one particular setting inside the SSIS packages that is getting misinterpreted. Of course, this information only applies to 64-bit architectures - if you are running a Windows 32-bit OS, you have no choice - your packages will always run in 32-bit mode.
Why would you want to run in 32-bit mode if you have a 64-bit system? Drivers, mostly. I'm not referring to hardware drivers, but data providers. As an example, Excel and some versions of Oracle don't have 64-bit providers. So for the ever-increasing base of 64-bit users, here's the skinny on executing Integration Services packages in your choice of 64-bit or 32-bit mode.
Background
I Can Design Fine, Why Won't It Run?
A little background to start. Business Intelligence Design Studio (BIDS) is a 32-bit application. When you're designing your package, you're using 32-bit facilities - and have no choice in the matter. When you execute your package using DTExec, you have the option of 32-bit or 64-bit operation - but the default on a 64-bit installation is to use 64-bit mode (obviously). However, some commonly used objects in SSIS don't have 64-bit counterparts, and will therefore cause your packages to fail.
Unfortunately, it usually doesn't say anywhere in these messages that the fault lies with 32 vs 64 bits. It's usually something like:
0x80040154 ... Class Not Registered
The AcquireConnection method call to the connection manager XXX failed with error code 0xC0202009
0xC00F9304 ... SSIS Error Code DTS_E_OLEDB_EXCEL_NOT_SUPPORTED
The OLE DB provider "Microsoft.Jet.OLEDB.4.0" has not been registered
(I include those sample errors here in the hope that those searching the web may find this article!)
Why Do I Want 32-bit Mode?
The most common reason to want 32-bit mode in an executing SSIS package is the Excel Provider. It's currently not available for 64 bits, and will cause your package to crash. (Office 14 (2010) is reported to have 64-bit support - even though it's not supported side-by-side with 32-bit.) This applies to the other Office providers as well - Access, specifically - and to several other third party drivers and providers (like Oracle). They simply will not work in a 64-bit environment (pre-2010). You may also wish to run Execute DTS 2000 Package Tasks - and those can only run in 32-bit mode as well.
It Depends How You're Executing Your Package
There are many ways to execute an SSIS package - and this is the primary determiner of whether you're running it in 64-bit or 32-bit mode. So pick your execution environment from the list below, and read up on how to force the bitness you desire.
Choosing Bitness Inside Business Intelligence Development Studio (BIDS)
If you're running your package inside BIDS, the setup is simple unless you're using the Execute Package Task or Execute Process Task to run child packages.
The package you currently have open will (by default) run in 64 bit mode. The setting that controls this is a property on the project called Run64BitRuntime. To access this property, right-click on the Integration Services project in your solution explorer and select Properties. Then select the Debugging node in the editor. The default here is "true", which means all the packages in this project will run in 64-bit mode. If you change this to "false", all the packages will be run in 32-bit mode.
Special Note: Execute Package Task
Any child packages executed via the Execute Package Task will run in the same mode as the parent, regardless of the Run64BitRuntime setting of the project that the child package belongs to, regardless of the setting of ExecuteOutOfProcess. This means that even if your child package has Run64BitRuntime set to false in the project you designed it in, it will be executed in 64-bit mode within BIDS if your parent package's Run64BitRuntime property is true.
Special Note: Execute Process Task
The Execute Process Task can allow you to choose 32-bit mode independently of the settings in the parent package, at the expense of running the child package in another process. As with the SQL Agent methods described later, you can specifically identify the 32-bit DTExec to run SSIS child packages in 32-bit mode (see below).
Choosing Bitness With SQL Agent
Instructing SQL Agent what environment you want your packages to run in is simple in Integration Services 2008. SSIS 2005 makes you jump through a few more hoops.
Integration Services 2008
In the Agent Job Step Properties, you'll be using the SQL Server Integration Services Package type of step. If you go to the Execution Options tab, you'll see an option to "Use 32 bit runtime" down at the bottom.
Integration Services 2005
With SQL 2005, you can not use the Integration Services Package type of job step to run an SSIS package in 32-bit mode. Your recourse is to use the Operating System type of job step, and refer to the 32-bit version of DTExec specifically in the command line that you use, and manually specify arguments to DTExec.
Hurdle #1 - Finding the 32-bit DTExec
Finding the executable shouldn't be difficult. In a standard 64-bit installation, the 32-bit DTExec.EXE should be located in the "\Program Files (x86)\Microsoft SQL Server\90\DTS\Binn" folder. It's plainly called "DTExec.EXE", and doesn't identify itself in any way as a 32-bit app - you'll have to "know" it is by it being located in the 32-bit folder. (Or you could try to execute it and watch Task Manager.) If you've installed SQL to a non-standard location, you may have to hunt a little. If you can't find it at all, you may not have installed the 32-bit components on your 64-bit machine. During the install of SQL Server, if you only selected "Integration Services" and didn't install "Business Intelligence Development Studio" OR "Management Tools - Complete", then you won't have the 32-bit DTExec installed. You'll have to run SQL Setup, and install one of those options.
Hurdle #2 - Determining the Command Line Arguments
Next, you need to determine the command line parameters you need to operate DTExec from the command line. You could read through the documentation and attempt to determine the arguments and settings by yourself, but I would recommend you use the power of the included GUI tools. Both the IS Job Step in SQL Agent, and the DTExecUI tool provide a GUI to configure an SSIS package run. On the last page of the GUI, it very helpfully places the exact command line arguments needed to run DTExec, based on all of the configuration options you've chosen on the ten or so other tabs of the GUI. Leverage that! Set up your package execution using the GUI, then copy the arguments off that last page.
Precompiled Scripts
This is only an issue in Integration Services 2005 - the dev team completely fixed this issue in SSIS 2008. There is a "Precompile" option on Script Tasks, which is set to "true" by default. If this has somehow been set to "false", your packages may not execute in a 64-bit environment.
32-bit ODBC Drivers
There is also one other oddity with using 32-bit ODBC drivers in Windows - at least in Server 2003, 2008, Vista, and Windows 7 64-bit OSes. The first step to using those drivers is to set up a DSN to handle storing the server name and other particulars. In my experience, the natural first place to start is by opening the "Data Sources" applet in the Control Panel. That's mistake #1 - because that applet only manages 64-bit drivers. You won't see yours listed at all. The next step is to poke around and realize that there's a "Data Sources (32-bit)" applet there in the Control Panel as well. That's mistake #2 - but not your mistake. In my experience, this icon leads to some odd hybrid 32/64 bit management utility. It definitely did NOT manage my 32-bit sources. If you fire it up, then look at the processes tab in Task Manager, you'll see a process labeled "odbcad32.exe"... but you'll notice that it doesn't have the "*32" after it denoting that it's a 32-bit app. Whatever it's attempting to manage, it's not the 32-bit ODBC drivers. What you need to do is navigate to another odbcad32.exe that's sitting in your SYSWOW64 folder. That ODBC data source administrator truly does manage 32-bit drivers, in a 32-bit process.
References/Resources
Most (if not all) of this information is also distilled in an MSDN article: 64-bit Considerations for Integration Services. If you find other useful articles, pointers, or mistakes in the above, please post a comment.
Some other very useful articles:
How To: Run a Package, MSDN
64-bit references within an SSIS Script Component by Michael Entin, Microsoft SSIS Dev.
64-bit Considerations for SQL Server Integration Services by Douglas Laudenschlager, Microsoft SSIS Dev.
Where is my app.config for SSIS? by Darren Green, SQL Server MVP.
Oracle Driver Configuration in a 64-bit environment by Rob Kerr
Importing data from 64-bit Excel in SSIS by Hrvoje Piasevoli
32- and 64-Bit Connectivity from the Same Machine by SQLCAT
Posted 18th October 2009 by Todd McDermid
When I setup SQL Server 2005 this problem appear
Minimum Hardware Requirement (Warning)
Messages Minimum Hardware Requirement
The current system does not meet the
minimum hardware requirements for this
SQL Server release. For detailed
hardware and software requirements,
see the readme file or SQL Server
Books Online.
and I continued setup but I could not found SQL Server Management Studio tools in start menu
As mentioned, you have missed installing SSMS. You can go through the install process again (you don't need to uninstall, just run it again), except this time make sure you put a check mark next to the Management tools when you do feature selections. I'd tell you exactly where it is but i only have a SQL2008 install on hand at the moment.
Your SQL is not completely installed, I suggest you to update all feature in your OS.
may be you installed Express edition?
also Management Studio is free, you can download it from link text
I de-installed SQL server 2005 express some time ago when I installed SQL server 2008 express.
Doing that install required windows installer 4.5.
Now I discover a reason to have SQL server 2005 express again.
(to reconnect to the outlook Business Contact Manager which requres it to connect to the default MSSQL\MSSMLBIZ database)
However, when I install any version of SQL server 2005, it fails for all the important things, like the database engine, with the message that I should upgrade my windows installer to a newer version.
I'm interpreting this as the SQL 2005 installer is experiencing failure and is presuming it is because the installer version is incorrect, and presuming the version is too previous.
But I suspect the version is too subsequent.
Any way out of this?
The error messages are produced by MSI-based installers are notoriously misleading (most installers silently swallow a lot of error conditions and present one single generic error message.) The best thing you could do is sift through the log files created by the SQL Server 2005 installer (IIRC, they're dumped into the %TMP% directory.) That will certainly provide more information.
You could try to uninstall the KB942288 package (Add/Remove Programs, make sure the Show updates checkbox is checked, and locate the corresponding entry.) Here's the corresponding Microsoft KB article as well. No guarantees as to what this will do to your system though, especially since you've certainly performed a lot of install actions since you installed 4.5.
You could also try one or more of the generic MSI debugging techniques described in KB 555175.
I have been running SQL Server 2005 Express Management Studio ("SSMSE"), and I now have a need to install the full version of Management Studio ("SSMS"). This is a known hassle, but I've not found a comprehensive way to carry it out.
At first, I uninstalled SSMSE, and then ran SqlRun_Tools.msi to install the toolset. I got this error message:
A component that you have specified in the ADD_LOCAL property is already
installed. To upgrade the existing component, refer to the template.ini
and set the UPGRADE property to the name of the component.
I had no idea what template.ini was. So I looked around, and decided to uninstall the rest of the minimal installation of SQL Server 2005 Express on my computer by following Microsoft's advice in KB 909967, "How to uninstall an instance of SQL Server 2005 manually." That bit was very successful.
But when I attempted to run SqlRun_Tools.msi again, I faced this mess when the installer was "Preparing Installation Wizard":
The setup has encountered an unexpected error in datastore. The action
is SetDialogs. The error is : Source File Name:
...\datastorecachexmlschema.cpp
**** Compiler Timestamp: Fri Jul 29 01:13:50 2005
**** Function Name: DataStoreCacheXMLSchema::initScopeRecord*****Sour...
(but replace the asterisks with box chars, which were probably CR-LF's in the original message)
This is very frustrating. Does anybody have any advice for installing the full version of SSMS over top of SSMSE? Any help you can provide would be greatly appreciated!
I have also installed SQL Management Studio before just using the SqlRun_Tools.msi package without any problems but I think if you have previously had any other SQL Server 2005 components installed then you will need to install the Setup Support Files first as this is probably what sets up the component installation sequence. This can be done either by installing from the SQL Server installation media or by running the sqlsupport.msi file as described in the Microsoft KB article.
I resolve this problem
Steps
Go to Add\remove program
unstall SQL server browser
Install support files from CD
Install SQL_Tools.MSI
Well, I roughly found out what the problem was, based on a somewhat cryptic resolution mentioned across a few different forums. This solution suggested that I needed to install Setup Support Files. Maybe it was reinstall, since I removed something with the same name when uninstalling SQL2K5 Express. I'm not sure if they were the same files, between the full version and the Express Edition.
I had tried reinstalling SQLXML4, the Native Client, and MSXML6 just to see if I could get beyond the error involving datastorecachexmlschema.cpp, and each time, I got the same error again. But I tried the technique mentioned in the above link, and it worked perfectly.
Basically, you insert the CD and run just the first part of the installation process, which installs the installation tools, including Setup Support Files. Then you cancel the rest of the installation process, and run SqlRun_Tools.msi instead.
I got great results when upgrading 2008 express to 2008 developer by (running setup) first going to Maintenance->Upgrade Edition, and then (since Management Tools etc was still "express" and I mainly needed the Sql Profiler) I also did a complete "new" installation (Installation->"New installation or add features.."), selecting the existing instance and then selecting all features.
No uninstall or command line necessary.
Behaved the same afterwards, just with new features.