MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » February 2013

Re: Microsoft Integration Services password



fixed

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

This email is confidential, intended only for the named recipient(s) above
and may contain information that is privileged. If you have received this
message in error or are not the named recipient(s), please notify the
sender immediately and delete this email message from your computer as any
and all unauthorized distribution or use of this message is strictly
prohibited. Thank you.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.







Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact