SSIS Connection manager not skipping specified header rows

Question

Post reply

SSIS Connection manager not skipping specified header rows

Kristopher Cook

Old Hand

Points: 335
More actions
January 8, 2010 at 12:00 pm

#229009

I am experiencing a problem with a header row in a flat file not being skipped. When I preview it in Visual Studio everythign is fine, but when I run the package, it tries to process the header row, resulting in an error. The configuration of the connection manager is set from an XML configuration file so that the package can be deployed to successive environments (Development, Test, Production) without changes to the package proper.
The entry below shows that the HeaderRowsToSkip is properly set to 1.
<Configuration ConfiguredType="Property" Path="\Package.Connections[US_Dealer_file].Properties[HeaderRowsToSkip]" ValueType="Int32">
<ConfiguredValue>1</ConfiguredValue>
I'm at a loss here, and can't find any mention online of anyone else experiencing this problem. Any ideas?
ADDITIONAL INFO: When I disable using configurations and set all of the parameters in the package, it works. Apparently, it DOES NOT READ THIS PARAMETER FROM THE .DTSConfig FILE.

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply

Matija Lah SSCertifiable Points: 6429 More actions · Answer 1

Have you verified which configuration file is being used at execution?

Have you verified that the file actually is use has the value set correctly?

SSIS config files can really be a pain to "where the sun don't shine" at times. 😉

ML

---
Matija Lah, SQL Server MVP
http://milambda.blogspot.com

Kristopher Cook Old Hand Points: 335 More actions · Answer 2

Both are verified. This is the first package of our move to implement this new strategy; there is only one package and one configuration file in the environment. It gets every other configuration value, but disregards this one. Just this one. Somehow, I do not consider this a feature ;-).

Matija Lah SSCertifiable Points: 6429 More actions · Answer 3

Weird. What has also worked for me in the past, even though I have no clue as to how or why, was as follows:

1) create a copy of the config file;

2) remove configuration from the package;

3) delete the old file (not the copy, of course);

4) re-enable the configuration creating a new config file;

5) save and close the SSIS project;

6) go to the config file folder, replace the newly created config file with the old copy;

7) open the SSIS project.

Officially this procedure is called "grasping at straws", but if you're sure you're using the correct file with the correct data then the whole thing is beyond weird.

ML

---
Matija Lah, SQL Server MVP
http://milambda.blogspot.com

Kristopher Cook Old Hand Points: 335 More actions · Answer 4

Un-<expletive>-believable. When I ran command-line (using DTExec.exe vs. DTExecUI) it ran. Que?

So I looked into it further, and found that when I double-clicked on the package to execute it, it was selecting the SQL 2005 DTExecUI. Registry entry vs. PATH statement.

So apparently the problem is in the SQL 2005 DTExecUI, which won't be a problem in production since the 2008 systems don't HAVE SQL 2005 on them to interfere.

I hate opaque configuration mechanisms.

Matija Lah SSCertifiable Points: 6429 More actions · Answer 5

Evil has no boundaries.

ML

---
Matija Lah, SQL Server MVP
http://milambda.blogspot.com