AS400 password request

Hi all,

I'm loading a working SSIS package in VB.NET and executing it programmatically. As the 'Persist Security Info' is set, it executes fine, presumably because I executed it previously with valid login info. But, when I update the connection info (programmatically) it prompts me for a password at runtime. The connection string will be provided by the user (DB Admin) and this is running as a Windows service, so what I want to do is, in the case of invalid login info, just receive a rejection, that I can respond to in the code. I'm using the IBMDA400 data provider to connect to an iSeries. Ideally, I need a generic solution that will apply to all connection strings and providers, if possible, but provider specific would be fine for now. Hope you can help....

Mazmo

i ran into this using 3 different AS400 connectors. Try making the Connection componments connection string a variable, and setting the connection string there. Fixed it for me, though security freaks would say this is bad. You could always encrypt your config file .|||

I'm pretty sure this won't solve my problem.

Regardless of the 'Persist Security Info' flag and whether it has connected previously, my customers will be creating the SSIS packages for my program to deal with. Wherever the connection string is stored, there will always be cases where it cannot authenticate. This is acceptable, as long as I can respond to the rejection by telling the user to edit their SSIS package and try again, instead of it automatically throwing up the login box.

So, basically, I want to supress the login box.

Any ideas?

|||We used a program called Macro Express that could track dialog boxes (amongst other things). This was our "Automation Process" before we got an open standards DMS. You could read the form title of the CLAE prompt, do a macro to email the person resonsible. Crummy workaround, but you are dealing with a 3rd party driver pop-up. So however else you do this in .net i don't know. Basically you will be screen scraping the environment, which menas you will also have to have the ssis running in a logged in user context, whcih goes over real well with sys admins (I hate it). Otherwise, maybe a windows programmer can shed some light on this using a pre-execute event or something.|||

maybe you could run a pre-emptive sql query against the 400 (such as SELECT 1+1) as a fake first step of you SSIS program. If it fails, send an email to somebody. Of course, it might time out and never trigger your catch clause.

(tried to edit but forums kept throwing errors...hopefully this gets through)