architecture

where is the actual physical location of views, sp's and dts packages?
The same place as was mention when you asked this question 4 times ago. :-)
"mat" wrote:

> where is the actual physical location of views, sp's and dts packages?

architecture

where is the actual physical location of views, sp's and dts packages?
Views and stored procs are objects within a database. Their definitions are
stored in sysobjects, syscomments, and others system tables within their
database. Physical storage is in the data files.
DTS package definitions are stored in msdb. Look for system tables named
like 'sysdts%'. Physical storage will be in the msdb data file.
DTS packages
"mat" wrote:

> where is the actual physical location of views, sp's and dts packages?
sql

architecture

where is the actual physical location of views, sp's and dts packages?
as far as I know, views and sps are part of your database file (.mdf) stored
as objects with the system tables. Typically a view is thought of as a
virtual table, or a stored query. The results of using a view are not
permanently stored in the database. The data accessed through a view is
actually constructed using standard T-SQL select command and can come from
one to many different base tables or even other views.
I hope this helps...
"mat" wrote:

> where is the actual physical location of views, sp's and dts packages?

Anyone who has permission to edit SPs can administer MS SQL server!

Hi!
One weekend a guy from development placed some sp_configure
instructions inside a procedure that is used by one of the jobs. So I
got this on the server:
Date Source Message
2004-06-06 16:17:27.16 spid91 Configuration option 'set working set
size' changed from 1 to 0. Run the RECONF
2004-06-06 16:17:27.25 spid91 Configuration option 'min memory per
query (KB)' changed from 4096 to 0. Run th
2004-06-06 16:17:27.36 spid91 Configuration option 'max worker
threads' changed from 255 to 0. Run the RECONF
2004-06-06 16:17:27.47 spid91 Configuration option 'max degree of
parallelism' changed from 2 to 0. Run the R
2004-06-06 16:17:27.58 spid91 Configuration option 'cost threshold for
parallelism' changed from 10 to 0. Run
2004-06-06 16:17:27.80 spid91 Configuration option 'remote access'
changed from 1 to 0. Run the RECONFIGURE s
2004-06-06 16:17:27.91 spid91 Configuration option 'remote proc trans'
changed from 1 to 0. Run the RECONFIGU
2004-06-06 16:17:28.02 spid91 Configuration option 'nested triggers'
changed from 1 to 0. Run the RECONFIGURE
This means that anyone who has permission to edit SPs can administer
MS SQL server! Such people can crush server, grant any rights to
themselves, etc. etc. Is there a way to block such activity?
Thanks.Hi,
I recommend you to configure the application specific jobs under the user
with only access
previlages to application tables.
If your job owner is "SA" or a user with SYSADMIN fixed role, you cant
restrict the access.
How to give the job owner:-
1. Doble click above the job
2. In the general tab, change the OWNER to a application user with less
previlages.
THis will restrict to run the adminstrative commands.
Other alternative is , Verify the procedures for admin commands before you
implement it to production. But you have spend time to search each
SP's which needs to be scheduled as a job.
Thanks
Hari
MCDBA
"Roust_m" <roustam@.hotbox.ru> wrote in message
news:a388fd78.0406080057.33c61cbc@.posting.google.com...
> Hi!
> One weekend a guy from development placed some sp_configure
> instructions inside a procedure that is used by one of the jobs. So I
> got this on the server:
> Date Source Message
> 2004-06-06 16:17:27.16 spid91 Configuration option 'set working set
> size' changed from 1 to 0. Run the RECONF
> 2004-06-06 16:17:27.25 spid91 Configuration option 'min memory per
> query (KB)' changed from 4096 to 0. Run th
> 2004-06-06 16:17:27.36 spid91 Configuration option 'max worker
> threads' changed from 255 to 0. Run the RECONF
> 2004-06-06 16:17:27.47 spid91 Configuration option 'max degree of
> parallelism' changed from 2 to 0. Run the R
> 2004-06-06 16:17:27.58 spid91 Configuration option 'cost threshold for
> parallelism' changed from 10 to 0. Run
> 2004-06-06 16:17:27.80 spid91 Configuration option 'remote access'
> changed from 1 to 0. Run the RECONFIGURE s
> 2004-06-06 16:17:27.91 spid91 Configuration option 'remote proc trans'
> changed from 1 to 0. Run the RECONFIGU
> 2004-06-06 16:17:28.02 spid91 Configuration option 'nested triggers'
> changed from 1 to 0. Run the RECONFIGURE
> This means that anyone who has permission to edit SPs can administer
> MS SQL server! Such people can crush server, grant any rights to
> themselves, etc. etc. Is there a way to block such activity?
> Thanks.