Re: Microsoft Integration Services password

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.
--