Showing posts with label enabled. Show all posts
Showing posts with label enabled. Show all posts

Wednesday, March 28, 2012

No Error thrown by SSIS on missing configuration files

Hello All,

I have a package in which I have enabled "Package Configuration".

When I run the package i am sure that it reads the configuration file and executes the package correctly.

However if I remove the configuration file, the package still executes correctly with the settings which were used at the time of development.

I have event handlers for OnError and OnWarning and both these are NOT invoked.

IMO, this is incorrect behavior because if a package has been configured for "package configuration, then we should atleast have a warning generated that SSIS did not find the configuration and it would execute the package with hard coded values (from the time of development).

Is there any work around for this? how can I make SSIS warn me if the config file is missing for a package which was configured for package configuration?

A missing configuration should trigger a warning and then the package uses the values provides at design time. I always get a the warnings.|||

What event handlers have you written?

I have written event handlers at package level for OnError and OnWarning

In both the event handlers I log the message into the windows event log.

The only messages I see in the windows event log is the "package started" and "package completed".

regards,

Abhishek.

|||I was talking about SSIS logining. I choose OnError and OnWarning.|||

The first thing I would look at is what circumstances are causing the configuration files to be missing at run time, as it seems like this is the root cause of your problem. The behavior you're describing appears to be "by design" to me - this is what I would expect, although I would also expect a warning to be logged if the configuration file were missing.

One possible workaround would be to have a Script task or custom component explicitly check for the existence of the file(s) before the main package logic executes, and only continue if the config files exist.

Another possible workaround would be to ensure that the design time values for the settings that should be set by the package configuration are obviously invalid. (For example, string that is not a valid path, or the like, depending on what you're setting in your configurations.) This would cause the package to fail outright at run time if the configuration could not be set, as opposed to executing with incorrect values and failing silently.

With that said, neither one of these workarounds seems particularly clean or ideal to me. I'd look at the root cause (why are the files missing) before doing anything else.

|||

> The first thing I would look at is what circumstances are causing the configuration files to be missing at run time

The circumstance is that we are testing our operations management strategy. We are deliberately causing things to go wrong in our test environment and we see if MOM (Microsoft Operations Manager) informs the admin correctly of what went wrong.

regards,

Abhishek.

Wednesday, March 21, 2012

No Client Protocols Enabled yet I can still get a DSN connection to SQL Server 2005

Perplexed...Why am I able to get a connection to my SQL Server from an
Access 2003 database via DSN linked SQL server db table without a
common protocol between the client and server? Could it be that the
client does have TCP/IP or Named Pipes enabled but they are just not
showing up in the cliconfg.exe utility as such? Help!Clients have always TCP/IP and/or Named Pipes enabled. This setting is for
the server, not for the client tools.
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"lacdn76" <dakarpiak@.yahoo.com> wrote in message
news:1175526801.931586.126790@.y66g2000hsf.googlegroups.com...
> Perplexed...Why am I able to get a connection to my SQL Server from an
> Access 2003 database via DSN linked SQL server db table without a
> common protocol between the client and server? Could it be that the
> client does have TCP/IP or Named Pipes enabled but they are just not
> showing up in the cliconfg.exe utility as such? Help!
>

No Client Protocols Enabled yet I can still get a DSN connection to SQL Server 2005

Perplexed...Why am I able to get a connection to my SQL Server from an
Access 2003 database via DSN linked SQL server db table without a
common protocol between the client and server? Could it be that the
client does have TCP/IP or Named Pipes enabled but they are just not
showing up in the cliconfg.exe utility as such? Help!
Clients have always TCP/IP and/or Named Pipes enabled. This setting is for
the server, not for the client tools.
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
"lacdn76" <dakarpiak@.yahoo.com> wrote in message
news:1175526801.931586.126790@.y66g2000hsf.googlegr oups.com...
> Perplexed...Why am I able to get a connection to my SQL Server from an
> Access 2003 database via DSN linked SQL server db table without a
> common protocol between the client and server? Could it be that the
> client does have TCP/IP or Named Pipes enabled but they are just not
> showing up in the cliconfg.exe utility as such? Help!
>