Persisting Package Variables

I was able to write successfully a Script Task to set the values of several package variables. But when the execution completes, the variables still contain values which were specified by default.

What I want is a method of persisting the values assigned to a variable through a script. I believe this was possible in DTS

The variable is not saved, because you have not saved the package. There is no way to do this really, so for anything you wish to persist between package executions you should store externally. If you want to see the value of variables during execution then use a breakpoint and drag the variables to the watch window. You do not see the value in BIDS because the package loaded in BIDS is not the same instance as that being executed. When you execute the package is saved, and a copy loaded into memory of the execution host. The copy in BIDS remains where it is as the debug copy.

In DTS when executing through Enterprise Manager it was the same copy, so you could see the value of variables post execution. The values were still not saved though, it was just a factor of you having only one instance of the package in memory. If you were executing through DTSRUN and variables changed they did not get persisted, as the package was not saved. The changed copy was thrown away once execution completed.

Permissions issue

I have an ASP website that uses SQL Server 2000 as its back end. It is
running successfully on SBS 2003--all on one machine. I am moving over to a
new domain which has the web site on one server and SQL Server 2000 on
another. I have progressed to the point where the web site comes up, but I
get error messages regarding permissions to SELECT, INSERT, etc. I can make
it work by setting the permission levels for each table, but I didn't need
to do that for the SBS setup. As far as I can tell, everything else is
configured the same way. I realize that I'm not giving you much information
at this point, but I'm hoping that this rings a bell of some sort and that
there is something I can do without having to set the permissions for each
table. Any ideas?
Hi
In the SBS world, the user that was connecting to the DB was probably SA or
had dbo role, so no object level permissions would be required.
Now, you need them as probably you have different permission set. The old
way would not have been very secure at all, as a hacker could have free
reign of your DB.
Are you using SQL Security, and what roles does the login have?
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"WC Justice" <wcjhome@.cox-internet.com> wrote in message
news:I8Koe.8490$I_1.2047@.okepread02...
>I have an ASP website that uses SQL Server 2000 as its back end. It is
> running successfully on SBS 2003--all on one machine. I am moving over to
> a
> new domain which has the web site on one server and SQL Server 2000 on
> another. I have progressed to the point where the web site comes up, but
> I
> get error messages regarding permissions to SELECT, INSERT, etc. I can
> make
> it work by setting the permission levels for each table, but I didn't need
> to do that for the SBS setup. As far as I can tell, everything else is
> configured the same way. I realize that I'm not giving you much
> information
> at this point, but I'm hoping that this rings a bell of some sort and that
> there is something I can do without having to set the permissions for each
> table. Any ideas?
>
|||I was using IUSR, with read permission only, and was using the following
connection string:
DSN=RLDP_SQL; UID=IUSR_WCJE05S;PWD=<>;DATABASE=RLDP_SQL;APP=ASPS cript;
TRUSTED_CONNECTION=YES
I have made the necessary changes to the connection string to allow for the
new DSN and ServerName, and it works, except for the permissions issue. If
I have to set the permission levels by table, that's not a problem. I just
wanted to make sure that I wasn't missing anything obvious.
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:%23fHHIZhaFHA.3712@.TK2MSFTNGP09.phx.gbl...
> Hi
> In the SBS world, the user that was connecting to the DB was probably SA
or[vbcol=seagreen]
> had dbo role, so no object level permissions would be required.
> Now, you need them as probably you have different permission set. The old
> way would not have been very secure at all, as a hacker could have free
> reign of your DB.
> Are you using SQL Security, and what roles does the login have?
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "WC Justice" <wcjhome@.cox-internet.com> wrote in message
> news:I8Koe.8490$I_1.2047@.okepread02...
to[vbcol=seagreen]
but[vbcol=seagreen]
need[vbcol=seagreen]
that[vbcol=seagreen]
each
>
|||I was using IUSR, with read permission only, and was using the following
connection string:
DSN=RLDP_SQL; UID=IUSR_WCJE05S;PWD=<>;DATABASE=RLDP_SQL;APP=ASPS cript;
TRUSTED_CONNECTION=YES
I have made the necessary changes to the connection string to allow for the
new DSN and ServerName, and it works, except for the permissions issue. If
I have to set the permission levels by table, that's not a problem. I just
wanted to make sure that I wasn't missing anything obvious.
Follow-Up: I found that if I make the IUSR a dbo, then it works great. Is
this a mistake from a security standpoint?
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:%23fHHIZhaFHA.3712@.TK2MSFTNGP09.phx.gbl...
> Hi
> In the SBS world, the user that was connecting to the DB was probably SA
> or had dbo role, so no object level permissions would be required.
> Now, you need them as probably you have different permission set. The old
> way would not have been very secure at all, as a hacker could have free
> reign of your DB.
> Are you using SQL Security, and what roles does the login have?
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "WC Justice" <wcjhome@.cox-internet.com> wrote in message
> news:I8Koe.8490$I_1.2047@.okepread02...
>

Permissions issue

I have an ASP website that uses SQL Server 2000 as its back end. It is
running successfully on SBS 2003--all on one machine. I am moving over to a
new domain which has the web site on one server and SQL Server 2000 on
another. I have progressed to the point where the web site comes up, but I
get error messages regarding permissions to SELECT, INSERT, etc. I can make
it work by setting the permission levels for each table, but I didn't need
to do that for the SBS setup. As far as I can tell, everything else is
configured the same way. I realize that I'm not giving you much information
at this point, but I'm hoping that this rings a bell of some sort and that
there is something I can do without having to set the permissions for each
table. Any ideas?Hi
In the SBS world, the user that was connecting to the DB was probably SA or
had dbo role, so no object level permissions would be required.
Now, you need them as probably you have different permission set. The old
way would not have been very secure at all, as a hacker could have free
reign of your DB.
Are you using SQL Security, and what roles does the login have?
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"WC Justice" <wcjhome@.cox-internet.com> wrote in message
news:I8Koe.8490$I_1.2047@.okepread02...
>I have an ASP website that uses SQL Server 2000 as its back end. It is
> running successfully on SBS 2003--all on one machine. I am moving over to
> a
> new domain which has the web site on one server and SQL Server 2000 on
> another. I have progressed to the point where the web site comes up, but
> I
> get error messages regarding permissions to SELECT, INSERT, etc. I can
> make
> it work by setting the permission levels for each table, but I didn't need
> to do that for the SBS setup. As far as I can tell, everything else is
> configured the same way. I realize that I'm not giving you much
> information
> at this point, but I'm hoping that this rings a bell of some sort and that
> there is something I can do without having to set the permissions for each
> table. Any ideas?
>|||I was using IUSR, with read permission only, and was using the following
connection string:
DSN=RLDP_SQL; UID=IUSR_WCJE05S;PWD=<>;DATABASE=RLDP_SQL;APP=ASPScript;
TRUSTED_CONNECTION=YES
I have made the necessary changes to the connection string to allow for the
new DSN and ServerName, and it works, except for the permissions issue. If
I have to set the permission levels by table, that's not a problem. I just
wanted to make sure that I wasn't missing anything obvious.
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:%23fHHIZhaFHA.3712@.TK2MSFTNGP09.phx.gbl...
> Hi
> In the SBS world, the user that was connecting to the DB was probably SA
or
> had dbo role, so no object level permissions would be required.
> Now, you need them as probably you have different permission set. The old
> way would not have been very secure at all, as a hacker could have free
> reign of your DB.
> Are you using SQL Security, and what roles does the login have?
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "WC Justice" <wcjhome@.cox-internet.com> wrote in message
> news:I8Koe.8490$I_1.2047@.okepread02...
to[vbcol=seagreen]
but[vbcol=seagreen]
need[vbcol=seagreen]
that[vbcol=seagreen]
each[vbcol=seagreen]
>|||I was using IUSR, with read permission only, and was using the following
connection string:
DSN=RLDP_SQL; UID=IUSR_WCJE05S;PWD=<>;DATABASE=RLDP_SQL;APP=ASPScript;
TRUSTED_CONNECTION=YES
I have made the necessary changes to the connection string to allow for the
new DSN and ServerName, and it works, except for the permissions issue. If
I have to set the permission levels by table, that's not a problem. I just
wanted to make sure that I wasn't missing anything obvious.
Follow-Up: I found that if I make the IUSR a dbo, then it works great. Is
this a mistake from a security standpoint?
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:%23fHHIZhaFHA.3712@.TK2MSFTNGP09.phx.gbl...
> Hi
> In the SBS world, the user that was connecting to the DB was probably SA
> or had dbo role, so no object level permissions would be required.
> Now, you need them as probably you have different permission set. The old
> way would not have been very secure at all, as a hacker could have free
> reign of your DB.
> Are you using SQL Security, and what roles does the login have?
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "WC Justice" <wcjhome@.cox-internet.com> wrote in message
> news:I8Koe.8490$I_1.2047@.okepread02...
>

Permission problems with sp_attach_db during installation

I successfully install SQL Express silently.

Then I try the following

-S .\INSTANCE -Q "sp_attach_db 'ATTACH_AS_NAME', 'C:\Program Files\APP_NAME\SQLData\APP_DB.MDF'"

This works...sometimes. But Many times I wll get a permissions error on the folder "C:\Program Files\APP_NAME". If I go and give "Everyone" "Full Permission" to the folder...it works fine.

My questions are:

1) What system users need access (and at what level) to this folder to do an attach? Because obviously giving everyone full access is bad.

2) Is there a better method for deploying a populated database with my application that this?

SQL service account needs modify privilege on "C:\Program Files\APP_NAME\SQLData\" path. If its running in Local system account then make sure SYSTEM or NT Authority \ System has modify privilege on the path
|||Do you know how to adjust the settings of that folder to allow that in a deployment package (Wise Install?)|||If you a trying to attach only the "mdf", use sp_attach_single_file_db and ignore your transaction log file(ldf)|||Hi,
1.) Click Start-->Run-->services.msc
2.) Check SQL Server startup account (Log On As)
3.) If its Local system then provide modify privilege for SYSTEM or NT Authority \ System for the folder "C:\Program Files\APP_NAME\SQLData\"
4.) If its some other ID provide modify privilege for the ID on "C:\Program Files\APP_NAME\SQLData\" folder.