Grant login to remotemachine\ASPNET

Hello Group,
I am working on an ASP.Net project. It will work on the same server that
runs SQL Server. For that reason all I did was grant the server's ASPNet
account access to the database. The problem is that when I am debugging
(from my remote machine) I can't connect because my station's ASPNet account
is not recognized by the server, as it only accept its own server\ASPNet
account.
How can I grant login to my remotemachine\ASPNet Account to that SQL Server?
Thanks ahead for all replies!
Giovanni BassiHi,
For debugging,USE domain user (Not remotemachine\ASPNet)
--
SHINICHI YONEDA MXL04371@.nifty.ne.jp
Microsoft Most Valuable Professional
MVP for SQL Server 2002-2003
"Giovanni Bassi" <gbassi@.coair.com> wrote in message
news:e66XMvNlDHA.1708@.TK2MSFTNGP12.phx.gbl...
> Hello Group,
> I am working on an ASP.Net project. It will work on the same server that
> runs SQL Server. For that reason all I did was grant the server's ASPNet
> account access to the database. The problem is that when I am debugging
> (from my remote machine) I can't connect because my station's ASPNet
account
> is not recognized by the server, as it only accept its own server\ASPNet
> account.
> How can I grant login to my remotemachine\ASPNet Account to that SQL
Server?
> Thanks ahead for all replies!
> Giovanni Bassi
>sql

Grant Create/Drop user Table permissions?

HI All,
I have a stored proc that runs and creates a temporary table for collecting
data and then drops it when it is done. My problem is that I can, as DBO,
run this fine but my users can not. How do I allow Create/Drop User tables
from a stored proc? Let me phrase that a different way; what kind of
permissions do I need to set up so that user's can run this stored proc that
creates/drops a temporary table? The stored proc already as the required
EXEC permissions for the user/groups to run it.
Thanks very much,
John.Hi John,
Your users don't need any special permissions to create temporary tables,
that is if you use real temporary tables, the ones prefixed with a #
character. From your narrative I get the impression that you use permanent
tables as temporary tables, but that is not advisable.
--
Jacco Schalkwijk
SQL Server MVP
"John Rugo" <jrugo@.patmedia.net> wrote in message
news:eytDgEa6DHA.2412@.TK2MSFTNGP09.phx.gbl...
> HI All,
> I have a stored proc that runs and creates a temporary table for
collecting
> data and then drops it when it is done. My problem is that I can, as DBO,
> run this fine but my users can not. How do I allow Create/Drop User
tables
> from a stored proc? Let me phrase that a different way; what kind of
> permissions do I need to set up so that user's can run this stored proc
that
> creates/drops a temporary table? The stored proc already as the required
> EXEC permissions for the user/groups to run it.
> Thanks very much,
> John.
>|||Hi,
You should give the below prev. to the normal database user.
grant create table to username
Drop table is not necessory because the owner who create the table can drop
the table.
Thanks
Hari
MCDBA
"John Rugo" <jrugo@.patmedia.net> wrote in message
news:eytDgEa6DHA.2412@.TK2MSFTNGP09.phx.gbl...
> HI All,
> I have a stored proc that runs and creates a temporary table for
collecting
> data and then drops it when it is done. My problem is that I can, as DBO,
> run this fine but my users can not. How do I allow Create/Drop User
tables
> from a stored proc? Let me phrase that a different way; what kind of
> permissions do I need to set up so that user's can run this stored proc
that
> creates/drops a temporary table? The stored proc already as the required
> EXEC permissions for the user/groups to run it.
> Thanks very much,
> John.
>|||Excellent Idea! I completely forgot about that.
Thanks very much :)
By the way, is it necessary to drop temporary tables and or check for their
existence before creating them?
Thanks again ,
John.
"Jacco Schalkwijk" <NOSPAMjaccos@.eurostop.co.uk> wrote in message
news:OUKZyOa6DHA.3704@.tk2msftngp13.phx.gbl...
Hi John,
Your users don't need any special permissions to create temporary tables,
that is if you use real temporary tables, the ones prefixed with a #
character. From your narrative I get the impression that you use permanent
tables as temporary tables, but that is not advisable.
--
Jacco Schalkwijk
SQL Server MVP
"John Rugo" <jrugo@.patmedia.net> wrote in message
news:eytDgEa6DHA.2412@.TK2MSFTNGP09.phx.gbl...
> HI All,
> I have a stored proc that runs and creates a temporary table for
collecting
> data and then drops it when it is done. My problem is that I can, as DBO,
> run this fine but my users can not. How do I allow Create/Drop User
tables
> from a stored proc? Let me phrase that a different way; what kind of
> permissions do I need to set up so that user's can run this stored proc
that
> creates/drops a temporary table? The stored proc already as the required
> EXEC permissions for the user/groups to run it.
> Thanks very much,
> John.
>|||Thanks for the correct syntax; I was drawing a mind blank this morning. Is
it possible to grant the same prev to a group instead of individual users?
John.
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:us9TIRa6DHA.3360@.tk2msftngp13.phx.gbl...
Hi,
You should give the below prev. to the normal database user.
grant create table to username
Drop table is not necessory because the owner who create the table can drop
the table.
Thanks
Hari
MCDBA
"John Rugo" <jrugo@.patmedia.net> wrote in message
news:eytDgEa6DHA.2412@.TK2MSFTNGP09.phx.gbl...
> HI All,
> I have a stored proc that runs and creates a temporary table for
collecting
> data and then drops it when it is done. My problem is that I can, as DBO,
> run this fine but my users can not. How do I allow Create/Drop User
tables
> from a stored proc? Let me phrase that a different way; what kind of
> permissions do I need to set up so that user's can run this stored proc
that
> creates/drops a temporary table? The stored proc already as the required
> EXEC permissions for the user/groups to run it.
> Thanks very much,
> John.
>|||Hi John,
Temporary tables are dropped automatically when they go out of scope, which
means that if you create a temporary table in a stored procedure the
temporary table will be dropped when the stored procedure completes. In any
case, temporary tables are dropped when the user diconnects from the
database, and internally temporary tables created by different users have
different names, although they all seem to have the same name to the users,
so multiple users can create the same temporary table at the same time.
--
Jacco Schalkwijk
SQL Server MVP
"John Rugo" <jrugo@.patmedia.net> wrote in message
news:uOWIdea6DHA.2760@.TK2MSFTNGP09.phx.gbl...
> Excellent Idea! I completely forgot about that.
> Thanks very much :)
> By the way, is it necessary to drop temporary tables and or check for
their
> existence before creating them?
> Thanks again ,
> John.
> "Jacco Schalkwijk" <NOSPAMjaccos@.eurostop.co.uk> wrote in message
> news:OUKZyOa6DHA.3704@.tk2msftngp13.phx.gbl...
> Hi John,
> Your users don't need any special permissions to create temporary tables,
> that is if you use real temporary tables, the ones prefixed with a #
> character. From your narrative I get the impression that you use permanent
> tables as temporary tables, but that is not advisable.
> --
> Jacco Schalkwijk
> SQL Server MVP
>
> "John Rugo" <jrugo@.patmedia.net> wrote in message
> news:eytDgEa6DHA.2412@.TK2MSFTNGP09.phx.gbl...
> > HI All,
> >
> > I have a stored proc that runs and creates a temporary table for
> collecting
> > data and then drops it when it is done. My problem is that I can, as
DBO,
> > run this fine but my users can not. How do I allow Create/Drop User
> tables
> > from a stored proc? Let me phrase that a different way; what kind of
> > permissions do I need to set up so that user's can run this stored proc
> that
> > creates/drops a temporary table? The stored proc already as the required
> > EXEC permissions for the user/groups to run it.
> >
> > Thanks very much,
> > John.
> >
> >
>
>

Grant Create/Drop user Table permissions?

HI All,
I have a stored proc that runs and creates a temporary table for collecting
data and then drops it when it is done. My problem is that I can, as DBO,
run this fine but my users can not. How do I allow Create/Drop User tables
from a stored proc? Let me phrase that a different way; what kind of
permissions do I need to set up so that user's can run this stored proc that
creates/drops a temporary table? The stored proc already as the required
EXEC permissions for the user/groups to run it.
Thanks very much,
John.Hi John,
Your users don't need any special permissions to create temporary tables,
that is if you use real temporary tables, the ones prefixed with a #
character. From your narrative I get the impression that you use permanent
tables as temporary tables, but that is not advisable.
Jacco Schalkwijk
SQL Server MVP
"John Rugo" <jrugo@.patmedia.net> wrote in message
news:eytDgEa6DHA.2412@.TK2MSFTNGP09.phx.gbl...

quote:

---

> HI All,
> I have a stored proc that runs and creates a temporary table for

---

collecting

quote:

---

> data and then drops it when it is done. My problem is that I can, as DBO,
> run this fine but my users can not. How do I allow Create/Drop User

---

tables

quote:

---

> from a stored proc? Let me phrase that a different way; what kind of
> permissions do I need to set up so that user's can run this stored proc

---

that

quote:

---

> creates/drops a temporary table? The stored proc already as the required
> EXEC permissions for the user/groups to run it.
> Thanks very much,
> John.
>

---

|||Hi,
You should give the below prev. to the normal database user.
grant create table to username
Drop table is not necessory because the owner who create the table can drop
the table.
Thanks
Hari
MCDBA
"John Rugo" <jrugo@.patmedia.net> wrote in message
news:eytDgEa6DHA.2412@.TK2MSFTNGP09.phx.gbl...

quote:

---

> HI All,
> I have a stored proc that runs and creates a temporary table for

---

collecting

quote:

---

> data and then drops it when it is done. My problem is that I can, as DBO,
> run this fine but my users can not. How do I allow Create/Drop User

---

tables

quote:

---

> from a stored proc? Let me phrase that a different way; what kind of
> permissions do I need to set up so that user's can run this stored proc

---

that

quote:

---

> creates/drops a temporary table? The stored proc already as the required
> EXEC permissions for the user/groups to run it.
> Thanks very much,
> John.
>

---

|||Excellent Idea! I completely forgot about that.
Thanks very much
By the way, is it necessary to drop temporary tables and or check for their
existence before creating them?
Thanks again ,
John.
"Jacco Schalkwijk" <NOSPAMjaccos@.eurostop.co.uk> wrote in message
news:OUKZyOa6DHA.3704@.tk2msftngp13.phx.gbl...
Hi John,
Your users don't need any special permissions to create temporary tables,
that is if you use real temporary tables, the ones prefixed with a #
character. From your narrative I get the impression that you use permanent
tables as temporary tables, but that is not advisable.
Jacco Schalkwijk
SQL Server MVP
"John Rugo" <jrugo@.patmedia.net> wrote in message
news:eytDgEa6DHA.2412@.TK2MSFTNGP09.phx.gbl...

quote:

---

> HI All,
> I have a stored proc that runs and creates a temporary table for

---

collecting

quote:

---

> data and then drops it when it is done. My problem is that I can, as DBO,
> run this fine but my users can not. How do I allow Create/Drop User

---

tables

quote:

---

> from a stored proc? Let me phrase that a different way; what kind of
> permissions do I need to set up so that user's can run this stored proc

---

that

quote:

---

> creates/drops a temporary table? The stored proc already as the required
> EXEC permissions for the user/groups to run it.
> Thanks very much,
> John.
>

---

|||Thanks for the correct syntax; I was drawing a mind blank this morning. Is
it possible to grant the same prev to a group instead of individual users?
John.
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:us9TIRa6DHA.3360@.tk2msftngp13.phx.gbl...
Hi,
You should give the below prev. to the normal database user.
grant create table to username
Drop table is not necessory because the owner who create the table can drop
the table.
Thanks
Hari
MCDBA
"John Rugo" <jrugo@.patmedia.net> wrote in message
news:eytDgEa6DHA.2412@.TK2MSFTNGP09.phx.gbl...

quote:

---

> HI All,
> I have a stored proc that runs and creates a temporary table for

---

collecting

quote:

---

> data and then drops it when it is done. My problem is that I can, as DBO,
> run this fine but my users can not. How do I allow Create/Drop User

---

tables

quote:

---

> from a stored proc? Let me phrase that a different way; what kind of
> permissions do I need to set up so that user's can run this stored proc

---

that

quote:

---

> creates/drops a temporary table? The stored proc already as the required
> EXEC permissions for the user/groups to run it.
> Thanks very much,
> John.
>

---

|||Hi John,
Temporary tables are dropped automatically when they go out of scope, which
means that if you create a temporary table in a stored procedure the
temporary table will be dropped when the stored procedure completes. In any
case, temporary tables are dropped when the user diconnects from the
database, and internally temporary tables created by different users have
different names, although they all seem to have the same name to the users,
so multiple users can create the same temporary table at the same time.
Jacco Schalkwijk
SQL Server MVP
"John Rugo" <jrugo@.patmedia.net> wrote in message
news:uOWIdea6DHA.2760@.TK2MSFTNGP09.phx.gbl...

quote:

---

> Excellent Idea! I completely forgot about that.
> Thanks very much
> By the way, is it necessary to drop temporary tables and or check for

---

their

quote:

---

> existence before creating them?
> Thanks again ,
> John.
> "Jacco Schalkwijk" <NOSPAMjaccos@.eurostop.co.uk> wrote in message
> news:OUKZyOa6DHA.3704@.tk2msftngp13.phx.gbl...
> Hi John,
> Your users don't need any special permissions to create temporary tables,
> that is if you use real temporary tables, the ones prefixed with a #
> character. From your narrative I get the impression that you use permanent
> tables as temporary tables, but that is not advisable.
> --
> Jacco Schalkwijk
> SQL Server MVP
>
> "John Rugo" <jrugo@.patmedia.net> wrote in message
> news:eytDgEa6DHA.2412@.TK2MSFTNGP09.phx.gbl...
> collecting
DBO,[QUOTE]
> tables
> that
>
>

---

sql

Good or Bad Idea? Multiple Tables for Data Import

Hello all,
We have an application which runs on a campaign basis. Data is loaded
throughout the day into our application. We typically load 20K - 30K rows
of data per campaign per day (total of about 150K - 200K row of data per
day).
We typically run about 30 - 35 campaigns simultaneously.
In order to increase the performance of our application, I was thinking of
loading each campaign into it's own table. The campaign tables would all be
identical. This would allow us to index each of these tables before each
campaign run to ensure the best possible performance.
What do you guys think?
We're finding that our application is being bogged down - we need to query
the tables continously as the application run... and return record sets
with minimal time.
Thanks.
Lucas Tam (REMOVEnntp@.rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
Newmarket Volvo Sucks! http://newmarketvolvo.tripod.com
Lucas
Have you read "Partitioned View" article in the BOL? If I understood you
correctly , that what you need .
"Lucas Tam" <REMOVEnntp@.rogers.com> wrote in message
news:Xns96D12EDD5C9ECnntprogerscom@.127.0.0.1...
> Hello all,
> We have an application which runs on a campaign basis. Data is loaded
> throughout the day into our application. We typically load 20K - 30K rows
> of data per campaign per day (total of about 150K - 200K row of data per
> day).
> We typically run about 30 - 35 campaigns simultaneously.
> In order to increase the performance of our application, I was thinking of
> loading each campaign into it's own table. The campaign tables would all
> be
> identical. This would allow us to index each of these tables before each
> campaign run to ensure the best possible performance.
> What do you guys think?
> We're finding that our application is being bogged down - we need to query
> the tables continously as the application run... and return record sets
> with minimal time.
> Thanks.
> --
> Lucas Tam (REMOVEnntp@.rogers.com)
> Please delete "REMOVE" from the e-mail address when replying.
> Newmarket Volvo Sucks! http://newmarketvolvo.tripod.com
|||"Uri Dimant" <urid@.iscar.co.il> wrote in
news:#O9$T2QuFHA.2076@.TK2MSFTNGP14.phx.gbl:

> Lucas
> Have you read "Partitioned View" article in the BOL? If I understood
> you correctly , that what you need .
Thanks URI, that seems to be what we need.
From your experience, would we gain a lot of performance by segmenting data
into it's own table?
Lucas Tam (REMOVEnntp@.rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
Newmarket Volvo Sucks! http://newmarketvolvo.tripod.com
|||Hi
Yes, if you have appropriate indexes defined on the table you will be
benefit from performance.
"Lucas Tam" <REMOVEnntp@.rogers.com> wrote in message
news:Xns96D180999FD22nntprogerscom@.127.0.0.1...
> "Uri Dimant" <urid@.iscar.co.il> wrote in
> news:#O9$T2QuFHA.2076@.TK2MSFTNGP14.phx.gbl:
>
> Thanks URI, that seems to be what we need.
> From your experience, would we gain a lot of performance by segmenting
> data
> into it's own table?
>
> --
> Lucas Tam (REMOVEnntp@.rogers.com)
> Please delete "REMOVE" from the e-mail address when replying.
> Newmarket Volvo Sucks! http://newmarketvolvo.tripod.com

Good or Bad Idea? Multiple Tables for Data Import

Hello all,
We have an application which runs on a campaign basis. Data is loaded
throughout the day into our application. We typically load 20K - 30K rows
of data per campaign per day (total of about 150K - 200K row of data per
day).
We typically run about 30 - 35 campaigns simultaneously.
In order to increase the performance of our application, I was thinking of
loading each campaign into it's own table. The campaign tables would all be
identical. This would allow us to index each of these tables before each
campaign run to ensure the best possible performance.
What do you guys think?
We're finding that our application is being bogged down - we need to query
the tables continously as the application run... and return record sets
with minimal time.
Thanks.
Lucas Tam (REMOVEnntp@.rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
Newmarket Volvo Sucks! http://newmarketvolvo.tripod.comLucas
Have you read "Partitioned View" article in the BOL? If I understood you
correctly , that what you need .
"Lucas Tam" <REMOVEnntp@.rogers.com> wrote in message
news:Xns96D12EDD5C9ECnntprogerscom@.127.0.0.1...
> Hello all,
> We have an application which runs on a campaign basis. Data is loaded
> throughout the day into our application. We typically load 20K - 30K rows
> of data per campaign per day (total of about 150K - 200K row of data per
> day).
> We typically run about 30 - 35 campaigns simultaneously.
> In order to increase the performance of our application, I was thinking of
> loading each campaign into it's own table. The campaign tables would all
> be
> identical. This would allow us to index each of these tables before each
> campaign run to ensure the best possible performance.
> What do you guys think?
> We're finding that our application is being bogged down - we need to query
> the tables continously as the application run... and return record sets
> with minimal time.
> Thanks.
> --
> Lucas Tam (REMOVEnntp@.rogers.com)
> Please delete "REMOVE" from the e-mail address when replying.
> Newmarket Volvo Sucks! http://newmarketvolvo.tripod.com|||"Uri Dimant" <urid@.iscar.co.il> wrote in
news:#O9$T2QuFHA.2076@.TK2MSFTNGP14.phx.gbl:

> Lucas
> Have you read "Partitioned View" article in the BOL? If I understood
> you correctly , that what you need .
Thanks URI, that seems to be what we need.
From your experience, would we gain a lot of performance by segmenting data
into it's own table?
Lucas Tam (REMOVEnntp@.rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
Newmarket Volvo Sucks! http://newmarketvolvo.tripod.com|||Hi
Yes, if you have appropriate indexes defined on the table you will be
benefit from performance.
"Lucas Tam" <REMOVEnntp@.rogers.com> wrote in message
news:Xns96D180999FD22nntprogerscom@.127.0.0.1...
> "Uri Dimant" <urid@.iscar.co.il> wrote in
> news:#O9$T2QuFHA.2076@.TK2MSFTNGP14.phx.gbl:
>
>
> Thanks URI, that seems to be what we need.
> From your experience, would we gain a lot of performance by segmenting
> data
> into it's own table?
>
> --
> Lucas Tam (REMOVEnntp@.rogers.com)
> Please delete "REMOVE" from the e-mail address when replying.
> Newmarket Volvo Sucks! http://newmarketvolvo.tripod.com

Good or Bad Idea? Multiple Tables for Data Import

Hello all,
We have an application which runs on a campaign basis. Data is loaded
throughout the day into our application. We typically load 20K - 30K rows
of data per campaign per day (total of about 150K - 200K row of data per
day).
We typically run about 30 - 35 campaigns simultaneously.
In order to increase the performance of our application, I was thinking of
loading each campaign into it's own table. The campaign tables would all be
identical. This would allow us to index each of these tables before each
campaign run to ensure the best possible performance.
What do you guys think?
We're finding that our application is being bogged down - we need to query
the tables continously as the application run... and return record sets
with minimal time.
Thanks.
--
Lucas Tam (REMOVEnntp@.rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
Newmarket Volvo Sucks! http://newmarketvolvo.tripod.comLucas
Have you read "Partitioned View" article in the BOL? If I understood you
correctly , that what you need .
"Lucas Tam" <REMOVEnntp@.rogers.com> wrote in message
news:Xns96D12EDD5C9ECnntprogerscom@.127.0.0.1...
> Hello all,
> We have an application which runs on a campaign basis. Data is loaded
> throughout the day into our application. We typically load 20K - 30K rows
> of data per campaign per day (total of about 150K - 200K row of data per
> day).
> We typically run about 30 - 35 campaigns simultaneously.
> In order to increase the performance of our application, I was thinking of
> loading each campaign into it's own table. The campaign tables would all
> be
> identical. This would allow us to index each of these tables before each
> campaign run to ensure the best possible performance.
> What do you guys think?
> We're finding that our application is being bogged down - we need to query
> the tables continously as the application run... and return record sets
> with minimal time.
> Thanks.
> --
> Lucas Tam (REMOVEnntp@.rogers.com)
> Please delete "REMOVE" from the e-mail address when replying.
> Newmarket Volvo Sucks! http://newmarketvolvo.tripod.com|||"Uri Dimant" <urid@.iscar.co.il> wrote in
news:#O9$T2QuFHA.2076@.TK2MSFTNGP14.phx.gbl:
> Lucas
> Have you read "Partitioned View" article in the BOL? If I understood
> you correctly , that what you need .
Thanks URI, that seems to be what we need.
From your experience, would we gain a lot of performance by segmenting data
into it's own table?
Lucas Tam (REMOVEnntp@.rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
Newmarket Volvo Sucks! http://newmarketvolvo.tripod.com|||Hi
Yes, if you have appropriate indexes defined on the table you will be
benefit from performance.
"Lucas Tam" <REMOVEnntp@.rogers.com> wrote in message
news:Xns96D180999FD22nntprogerscom@.127.0.0.1...
> "Uri Dimant" <urid@.iscar.co.il> wrote in
> news:#O9$T2QuFHA.2076@.TK2MSFTNGP14.phx.gbl:
>> Lucas
>> Have you read "Partitioned View" article in the BOL? If I understood
>> you correctly , that what you need .
>
> Thanks URI, that seems to be what we need.
> From your experience, would we gain a lot of performance by segmenting
> data
> into it's own table?
>
> --
> Lucas Tam (REMOVEnntp@.rogers.com)
> Please delete "REMOVE" from the e-mail address when replying.
> Newmarket Volvo Sucks! http://newmarketvolvo.tripod.com

Globals.Referrer?

Regards,
We need to setup a report so that it only runs if the referrer is a certain
URL. This is so that end users cannot directly navigate to the report (or
if they know the URL, plop it into the address bar and navigate there).
Instead, we'd like the report to check if they're coming from a particular
application and run ONLY if it sees that it's coming from that application.
Any ideas?
Any help would be greatly appreciated!
Benjamin PierceI would
Try to write some code to override the on_init method of the report and
check for the referrer
--
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Benjamin Pierce" <bpierce@.opentext.com> wrote in message
news:uWIxXNyWFHA.3240@.TK2MSFTNGP10.phx.gbl...
> Regards,
> We need to setup a report so that it only runs if the referrer is a
> certain
> URL. This is so that end users cannot directly navigate to the report (or
> if they know the URL, plop it into the address bar and navigate there).
> Instead, we'd like the report to check if they're coming from a particular
> application and run ONLY if it sees that it's coming from that
> application.
> Any ideas?
> Any help would be greatly appreciated!
>
> Benjamin Pierce
>|||Is the On_Imit method part of SQL 2005 Reporting Services? I wasn't aware
of report methods in SQL 2000.
Let me know.
Thanks!
Ben
"Wayne Snyder" <wayne.nospam.snyder@.mariner-usa.com> wrote in message
news:%237pUQr4WFHA.2796@.TK2MSFTNGP09.phx.gbl...
> I would
> Try to write some code to override the on_init method of the report and
> check for the referrer
> --
> Wayne Snyder, MCDBA, SQL Server MVP
> Mariner, Charlotte, NC
> www.mariner-usa.com
> (Please respond only to the newsgroups.)
> I support the Professional Association of SQL Server (PASS) and it's
> community of SQL Server professionals.
> www.sqlpass.org
> "Benjamin Pierce" <bpierce@.opentext.com> wrote in message
> news:uWIxXNyWFHA.3240@.TK2MSFTNGP10.phx.gbl...
> > Regards,
> >
> > We need to setup a report so that it only runs if the referrer is a
> > certain
> > URL. This is so that end users cannot directly navigate to the report
(or
> > if they know the URL, plop it into the address bar and navigate there).
> > Instead, we'd like the report to check if they're coming from a
particular
> > application and run ONLY if it sees that it's coming from that
> > application.
> >
> > Any ideas?
> >
> > Any help would be greatly appreciated!
> >
> >
> > Benjamin Pierce
> >
> >
>

Giving users specific DDL permissions

I have an archival process on a large database that runs once a month.
At the beginning of the process the triggers and indexes on the
tables whose data is moved are dropped, the data is moved and then the
triggers and indexes are recreated at the end. This produces a
massive improvement in performance.

The problem is the process is supposed to run on users accounts (thats
the way the front-end is set up) and they don't have the neccessary
permissions to drop & create triggers & indexes. I can't see any way
to give them permissions only on specific tables or triggers/indexes.
Nor does giving them permissions to the stored procedures that do the
dropping & re-creating work, DDL permissions don't seem to be
inherited the way they are with tables.

Is blanket rights to drop & create objects through the db_ddladmin
role the only way users can get rights?

Thanks,

K FineganK Finegan (KevinFinegan@.Hotmail.com) writes:
> I have an archival process on a large database that runs once a month.
> At the beginning of the process the triggers and indexes on the
> tables whose data is moved are dropped, the data is moved and then the
> triggers and indexes are recreated at the end. This produces a
> massive improvement in performance.
> The problem is the process is supposed to run on users accounts (thats
> the way the front-end is set up) and they don't have the neccessary
> permissions to drop & create triggers & indexes. I can't see any way
> to give them permissions only on specific tables or triggers/indexes.
> Nor does giving them permissions to the stored procedures that do the
> dropping & re-creating work, DDL permissions don't seem to be
> inherited the way they are with tables.
> Is blanket rights to drop & create objects through the db_ddladmin
> role the only way users can get rights?

In SQL2000, yes. The upcoming version of SQL Server has some more
possibilities.

As for the triggers, it's probably better to say ALTER TABLE DISABLE
TRIGGERS ALL, than to drop them. Not that this addresses the permissions
problem.

There is a way to have a trigger off-turnable by means of regular
permissions though. In the trigger body you do this:

IF object_id('tempdb..#reloading') IS NULL
... Trigger logic comes here.

In you process you would create this temp table. The test would save you
the logic of the trigger, but you may still have an overhead, because
SQL Server has to run the statement as if there trigger was active.

No, for indexes I don't have any tricks.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Thanks Erland, I like the trigger trick, will probably use it &
DISABLE which I didn't know about. Pity about the indexes. For the
moment I suppose I'll have to give one (trustworthy) user ddl_admin
rights.

K Finegan