> Problem at hand: Moving / Migrating jobs from development to test to
> production.
> Current situation: SQL servers are instances in many cases and not
> necessarily "local". A "common" SQL database is used to store connection
> information that is read using dynamic properties task to modify the SQL
> Server / username settings from within the DTS job.
>
> Question: If my understanding is correct, the password cannot be set
anyway
> due to a bug and we have to rely on Windows authentication. Can we use
> ODBC-DSN names to establish connections to source and target SQL servers
in
> the different environments (dev, test and production) instead of this
> dynamic properties task. Is there an advantage / disadvantage to using
DSNs
> or some unknown hidden problem that I seem to be missing. The security of
the
> passwords and the different server names across the dev cycle, can be
> administered by an administrator thereby not letting the developers have
> access to production etc.
>
> Any insights would be great!
>
> Rangarajan
> *********
>
>