Re: Microsoft Integration Services password

[Richard Schoen <richard@xxxxxxxxxxxxxxx>]

This is not necessarily a fault with Scotts code, but I was able to get the JVM to fall over pretty easily by throwing some odd data types and invalid queries into the mix.

Just saying make sure to test all scenarios if you go down the Java/Mix RPG Route. If I'm using Java I write a true Java class and then call it from CL.  Much more stable. 

Regards,
Richard Schoen
RJS Software Systems Inc.
Where Information Meets Innovation
Document Management, Workflow, Report Delivery, Forms and Business Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site: http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT

------------------------------

message: 2
date: Wed, 20 Feb 2013 17:41:26 -0700
from: Alan Campin <alan0307d@xxxxxxxxx>
subject: Re: Microsoft Integration Services password

I would definitely recommend using Scott JDBC api to call stored procedures to extract information or update. It is running on the i and you don't have all the intermittent stuff running with potential to fail.


On Wed, Feb 20, 2013 at 5:17 PM, Porterfield, Sean < SPorterfield@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

> I've been using DTS for years on SQL Server 2005 to pull data from our 
> IBM i (or whatever it was called then ;) )
>
> Now I have a new project on SQL Server 2008, so I used Integration 
> Services to pull the data.  I automate it from a batch job when the 
> data is ready, calling RUNRMTCMD to DTEXEC on the Windows box.
>
> Whenever the Windows box is rebooted, I have to log on as the user 
> listed in the RUNRMTCMD, start the data transfer process, and key the 
> IBM i user password in the normal System i Access password dialog.  It 
> then works fine, even after logging off, until the system is rebooted again.
>
> Does anyone know a way to make it keep the password?  I typed it in 
> the ODBC properties when I created the IS process, but it doesn't store it.
>
> If not, (or regardless) what would others recommend for a data 
> transfer process?  At this time, I don't think I'm actually changing 
> any of the data, just using TRUNCATE TABLE and pulling in an entire *PF to replace it.
>
> I was thinking it's probably possible and not horribly difficult to do 
> in PHP, but I've only ever done that for a single record update.  JDBC 
> comes to mind as another option, though I've never installed or used 
> it.  It seems more logical to run the entire process from the i 
> instead of having to bounce back and forth.
> --