"Allan Mitchell" <allan@no-spam.sqldts.com> wrote in message news:OJJn6B15DHA.2412@TK2MSFTNGP11.phx.gbl...
> If the packages are coming over from DEV then the Hard Coded strings should
> be pointing to the DEV system no?

> I presume that you set the Global Variable at Runtime and replace with the
> values necessary for each environment.

> You should really check each package as it comes through to you on the
> production server, allowing DEV to push their packages through to LIVE with
> no checking would not be my preferred way of doing things.

> Turn access to the production server to whom or what?

> You could remove guest from MSDB.

> How are the packages being called?

> Allan Mitchell MCSE,MCDBA, (Microsoft SQL Server MVP)
> www.allisonmitchell.com - Expert SQL Server Consultancy.
> www.SQLDTS.com - The site for all your DTS needs.
> I support PASS - the definitive, global community
> for SQL Server professionals - http://www.sqlpass.org

> "Lee Gillie" <ANTISPAMIFICATION_lee@odp.com> wrote in message
> news:ODbxN205DHA.2072@TK2MSFTNGP11.phx.gbl...
> > The scenario is probably pretty common. There is a lot of new DTS package
> development work by a number of people at our location,
> > and others. The target for installation is a production server located
> elsewhere. Everyone here has access to the production server,
> > to look at data, perhaps make schema changes, push DTS packages, etc. This
> access is allowed to help expidite the development
> > process.
> >
> > The "rule" is that you are ONLY supposed to have SQL connection strings in
> DTS connection objects - AND - there is a standard of
> > placing this string in Global Variables, for use in script. But it CAN
> happen, of course, that in the heat of the moment, someone
> > can hard code a connection string into an ActiveX script. The test package
> could then run awry, and destroy important information on
> > the production server.
> >
> > I am wondering if there might be some easy way to turn access to the
> production server off and on. It would need to be a quick easy
> > thing to do. The production server is in a different domain, and we use NT
> authentication. From the development domain, where the
> > change needs to be initiated, we do not have the adminstrative rights to
> change security settings on the production server. We are
> > hoping there may be a solution to change access in our domain (perhaps
> without resorting to separate logons for the function).

"Lee Gillie" <ANTISPAMIFICATION_lee@odp.com> wrote in message
news:ODbxN205DHA.2072@TK2MSFTNGP11.phx.gbl...
> The scenario is probably pretty common. There is a lot of new DTS package
development work by a number of people at our location,
> and others. The target for installation is a production server located
elsewhere. Everyone here has access to the production server,
> to look at data, perhaps make schema changes, push DTS packages, etc. This
access is allowed to help expidite the development
> process.
>
> The "rule" is that you are ONLY supposed to have SQL connection strings in
DTS connection objects - AND - there is a standard of
> placing this string in Global Variables, for use in script. But it CAN
happen, of course, that in the heat of the moment, someone
> can hard code a connection string into an ActiveX script. The test package
could then run awry, and destroy important information on
> the production server.
>
> I am wondering if there might be some easy way to turn access to the
production server off and on. It would need to be a quick easy
> thing to do. The production server is in a different domain, and we use NT
authentication. From the development domain, where the
> change needs to be initiated, we do not have the adminstrative rights to
change security settings on the production server. We are
> hoping there may be a solution to change access in our domain (perhaps
without resorting to separate logons for the function).
>
>

"Lee Gillie" <ANTISPAMIFICATION_lee@odp.com> wrote in message
news:O0m8D415DHA.2392@TK2MSFTNGP11.phx.gbl...
> Allan - This is definitely a shot-in-the-dark question. But I appreciate
your considering it.
>
> "Allan Mitchell" <allan@no-spam.sqldts.com> wrote in message
news:OJJn6B15DHA.2412@TK2MSFTNGP11.phx.gbl...
> > If the packages are coming over from DEV then the Hard Coded strings
should
> > be pointing to the DEV system no?
>
> Not necessarily. A package may have been written at, or placed into
service at the production server. Then enhancement may be
> needed, so it is shipped down (or back) to us. We then "localized" it, but
miss an inadvertent hard-code.
>
> > I presume that you set the Global Variable at Runtime and replace with
the
> > values necessary for each environment.
>
> The "rule" is that you are ONLY supposed to have SQL connection strings in
DTS connection objects - AND - there is a standard of
> placing this string in Global Variables, for use in script. But we are
trying to protect against cockpit errors, where either
> someone fails or forgets, or the package (incorrectly) contains hard coded
connect strings in ActiveX script.
>
> > You should really check each package as it comes through to you on the
> > production server, allowing DEV to push their packages through to LIVE
with
> > no checking would not be my preferred way of doing things.
>
> Agreed, and I hope I presented this is the goal. But we are looking for a
mechanism, which may or may not exist, that can help us
> provide a level of protection for errors - hence the question.
>
> > Turn access to the production server to whom or what?
>
> If we could temporarily make it so the developer can not connect to the
production database, and only his sandbox database, from his
> workstation, that would pretty much accomplish it. Two functions like
"dissallow this workstation to connect to this SQL Server",
> and antoher "allow connection again", which we could toggle from our side.
>
> > You could remove guest from MSDB.
>
> From the development domain, where the change needs to be initiated, we do
not have the adminstrative rights to change security
> settings on the production server.
>
> > How are the packages being called?
>
> Currently developers are running from their workstations, in EM, and are
SUPPOSED to be running against a sandbox development server
> we have locally. So they may be running a package, or a single task, etc.
>
> > Allan Mitchell MCSE,MCDBA, (Microsoft SQL Server MVP)
> > www.allisonmitchell.com - Expert SQL Server Consultancy.
> > www.SQLDTS.com - The site for all your DTS needs.
> > I support PASS - the definitive, global community
> > for SQL Server professionals - http://www.sqlpass.org
>
> Allan - I really doubt there is a simple solution. But I thought I would
ask in case someone had found a really nice way to deal
> with this.
>
> > "Lee Gillie" <ANTISPAMIFICATION_lee@odp.com> wrote in message
> > news:ODbxN205DHA.2072@TK2MSFTNGP11.phx.gbl...
> > > The scenario is probably pretty common. There is a lot of new DTS
package
> > development work by a number of people at our location,
> > > and others. The target for installation is a production server located
> > elsewhere. Everyone here has access to the production server,
> > > to look at data, perhaps make schema changes, push DTS packages, etc.
This
> > access is allowed to help expidite the development
> > > process.
> > >
> > > The "rule" is that you are ONLY supposed to have SQL connection
strings in
> > DTS connection objects - AND - there is a standard of
> > > placing this string in Global Variables, for use in script. But it CAN
> > happen, of course, that in the heat of the moment, someone
> > > can hard code a connection string into an ActiveX script. The test
package
> > could then run awry, and destroy important information on
> > > the production server.
> > >
> > > I am wondering if there might be some easy way to turn access to the
> > production server off and on. It would need to be a quick easy
> > > thing to do. The production server is in a different domain, and we
use NT
> > authentication. From the development domain, where the
> > > change needs to be initiated, we do not have the adminstrative rights
to
> > change security settings on the production server. We are
> > > hoping there may be a solution to change access in our domain (perhaps
> > without resorting to separate logons for the function).
>
>