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

Rangarajan,

ODBC is just another layer with its own quirks and a bit slower. To my
opinion closer to the data the better. As to windows authentication it is as
flexible as sql server one and more secure.

Ilya

"Rangarajan Suresh" <RangarajanSuresh (AT) discussions (DOT) microsoft.com> wrote in
message news:B6AE3D0A-2318-4585-B571-77D1FE852659 (AT) microsoft (DOT) com...