Metadata Services: protection

Showing posts with label protection. Show all posts

Monday, March 19, 2012

Nightly Update / Fallback protection

I have become involved with an assessment of a client's nightly update
procedures, and I keep running into the following practice.
The client consistently copies databases off to separate locations and
performs updates upon the new copy. After successful update, the
updated database is then copied back to the origin location and
becomes the new version. All of this, obviously, to protect
themselves in case of error. I can't help but suspect that SQL Server
provides an easier way to do it.
In the mainframe universe, this used to be accomplished via
generational datasets which would be promoted as the baseline when the
update completes. I guess what I'm asking is if SQL Server provides
any kind of "checkpoint-fallback" capability that the client could use
instead of this monstrous time-consuming practice. When talking
thousands of updates in a batch, I'm not sure transactioning would be
the best way to do it. That would be one big honking rollback.
Thanks in advance to any of you architects out there!
SQL Server 2005 (Enterprise Edition) has, sort of, this. You can create a "database snapshot"
(CREATE DATABASE Copy AS SNAPSHOT OF Orig). The database files for the Copy database are initially
empty and consume close to 0 disk space, i.e., the snapshot takes only a few seconds to take. Then
modify your Orig database. As you modify Orig database, the pages to be modified are first copied to
the Copy databases' database files. This way, the copy database always has the data as it was when
the snapshot was produced. If you need to "fall-back", then you can RESTORE DATABASE Orig FROM
DATABASE_SNAPSHOT 'Copy', and all pages (in the Copy databases' database files) are copied back to
the Orig database' files and you are back where you began. Concept is called "Copy on write".
Same-same (concept) but different (implementation). :-)
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"BizEd" <EdMathias18@.gmail.com> wrote in message
news:1177351816.251254.221810@.b58g2000hsg.googlegr oups.com...
>I have become involved with an assessment of a client's nightly update
> procedures, and I keep running into the following practice.
> The client consistently copies databases off to separate locations and
> performs updates upon the new copy. After successful update, the
> updated database is then copied back to the origin location and
> becomes the new version. All of this, obviously, to protect
> themselves in case of error. I can't help but suspect that SQL Server
> provides an easier way to do it.
> In the mainframe universe, this used to be accomplished via
> generational datasets which would be promoted as the baseline when the
> update completes. I guess what I'm asking is if SQL Server provides
> any kind of "checkpoint-fallback" capability that the client could use
> instead of this monstrous time-consuming practice. When talking
> thousands of updates in a batch, I'm not sure transactioning would be
> the best way to do it. That would be one big honking rollback.
> Thanks in advance to any of you architects out there!
>
|||It is called a backup before you do any changes. Then if there is an issue
you simply restore.
Andrew J. Kelly SQL MVP
"BizEd" <EdMathias18@.gmail.com> wrote in message
news:1177351816.251254.221810@.b58g2000hsg.googlegr oups.com...
>I have become involved with an assessment of a client's nightly update
> procedures, and I keep running into the following practice.
> The client consistently copies databases off to separate locations and
> performs updates upon the new copy. After successful update, the
> updated database is then copied back to the origin location and
> becomes the new version. All of this, obviously, to protect
> themselves in case of error. I can't help but suspect that SQL Server
> provides an easier way to do it.
> In the mainframe universe, this used to be accomplished via
> generational datasets which would be promoted as the baseline when the
> update completes. I guess what I'm asking is if SQL Server provides
> any kind of "checkpoint-fallback" capability that the client could use
> instead of this monstrous time-consuming practice. When talking
> thousands of updates in a batch, I'm not sure transactioning would be
> the best way to do it. That would be one big honking rollback.
> Thanks in advance to any of you architects out there!
>
|||On Apr 23, 1:23 pm, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> SQL Server 2005 (Enterprise Edition) has, sort of, this. You can create a "database snapshot"
> (CREATE DATABASE Copy AS SNAPSHOT OF Orig). The database files for the Copy database are initially
> empty and consume close to 0 disk space, i.e., the snapshot takes only a few seconds to take. Then
> modify your Orig database. As you modify Orig database, the pages to be modified are first copied to
> the Copy databases' database files. This way, the copy database always has the data as it was when
> the snapshot was produced. If you need to "fall-back", then you can RESTORE DATABASE Orig FROM
> DATABASE_SNAPSHOT 'Copy', and all pages (in the Copy databases' database files) are copied back to
> the Orig database' files and you are back where you began. Concept is called "Copy on write".
> Same-same (concept) but different (implementation). :-)
> --
> Tibor Karaszi, SQL Server MVPhttp://www.karaszi.com/sqlserver/default.asphttp://sqlblog.com/blogs/tibor_karaszi
> "BizEd" <EdMathia...@.gmail.com> wrote in message
> news:1177351816.251254.221810@.b58g2000hsg.googlegr oups.com...
>
>
>
> - Show quoted text -
Tibor,
Thanks. That's the type of functionality I was looking for. A simple
backup is not a sufficient solution when you are talking about a
multiple stage update process. If you wish to restart a step in the
process, the backup would necessitate going all the way back to the
beginning. Your solution is in essence "a delta file" which provides
functionality much more in line with the concept of mainframe
generational data sets!
Now to get the client on to SQL 2005....harrumph!
|||Note that you can have several "delta-files" (several database snapshots). But if you want to
restore from any of them, you need for first DROP DATABASE for all those snapshots except the one to
restore from.
Another important thing is that when you restore from a database snapshot, you break the log backup
chain sequence for your database. So, if you are doing log backups for that database, you want to do
a BACKUP DATABASE after restoring from a database snapshot.
And, as always, make sure you read all about this in Books Online first. :-)
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"BizEd" <EdMathias18@.gmail.com> wrote in message
news:1177365104.403457.180780@.b58g2000hsg.googlegr oups.com...
> On Apr 23, 1:23 pm, "Tibor Karaszi"
> <tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> Tibor,
> Thanks. That's the type of functionality I was looking for. A simple
> backup is not a sufficient solution when you are talking about a
> multiple stage update process. If you wish to restart a step in the
> process, the backup would necessitate going all the way back to the
> beginning. Your solution is in essence "a delta file" which provides
> functionality much more in line with the concept of mainframe
> generational data sets!
> Now to get the client on to SQL 2005....harrumph!
>
|||As a standard process, this seems excessive.
You are aware that within the processing, SQLServer (like most major
databases) allows you to define a transaction that holds off
commitment until all the steps have completed successfully, and can be
rolled back if any errors are detected?
Josh
On 23 Apr 2007 11:10:16 -0700, BizEd <EdMathias18@.gmail.com> wrote:

>I have become involved with an assessment of a client's nightly update
>procedures, and I keep running into the following practice.
>The client consistently copies databases off to separate locations and
>performs updates upon the new copy. After successful update, the
>updated database is then copied back to the origin location and
>becomes the new version. All of this, obviously, to protect
>themselves in case of error. I can't help but suspect that SQL Server
>provides an easier way to do it.
>In the mainframe universe, this used to be accomplished via
>generational datasets which would be promoted as the baseline when the
>update completes. I guess what I'm asking is if SQL Server provides
>any kind of "checkpoint-fallback" capability that the client could use
>instead of this monstrous time-consuming practice. When talking
>thousands of updates in a batch, I'm not sure transactioning would be
>the best way to do it. That would be one big honking rollback.
>Thanks in advance to any of you architects out there!

Nightly Update / Fallback protection

I have become involved with an assessment of a client's nightly update
procedures, and I keep running into the following practice.
The client consistently copies databases off to separate locations and
performs updates upon the new copy. After successful update, the
updated database is then copied back to the origin location and
becomes the new version. All of this, obviously, to protect
themselves in case of error. I can't help but suspect that SQL Server
provides an easier way to do it.
In the mainframe universe, this used to be accomplished via
generational datasets which would be promoted as the baseline when the
update completes. I guess what I'm asking is if SQL Server provides
any kind of "checkpoint-fallback" capability that the client could use
instead of this monstrous time-consuming practice. When talking
thousands of updates in a batch, I'm not sure transactioning would be
the best way to do it. That would be one big honking rollback.
Thanks in advance to any of you architects out there!SQL Server 2005 (Enterprise Edition) has, sort of, this. You can create a "d
atabase snapshot"
(CREATE DATABASE Copy AS SNAPSHOT OF Orig). The database files for the Copy
database are initially
empty and consume close to 0 disk space, i.e., the snapshot takes only a few
seconds to take. Then
modify your Orig database. As you modify Orig database, the pages to be modi
fied are first copied to
the Copy databases' database files. This way, the copy database always has t
he data as it was when
the snapshot was produced. If you need to "fall-back", then you can RESTORE
DATABASE Orig FROM
DATABASE_SNAPSHOT 'Copy', and all pages (in the Copy databases' database fil
es) are copied back to
the Orig database' files and you are back where you began. Concept is called
"Copy on write".
Same-same (concept) but different (implementation). :-)
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"BizEd" <EdMathias18@.gmail.com> wrote in message
news:1177351816.251254.221810@.b58g2000hsg.googlegroups.com...
>I have become involved with an assessment of a client's nightly update
> procedures, and I keep running into the following practice.
> The client consistently copies databases off to separate locations and
> performs updates upon the new copy. After successful update, the
> updated database is then copied back to the origin location and
> becomes the new version. All of this, obviously, to protect
> themselves in case of error. I can't help but suspect that SQL Server
> provides an easier way to do it.
> In the mainframe universe, this used to be accomplished via
> generational datasets which would be promoted as the baseline when the
> update completes. I guess what I'm asking is if SQL Server provides
> any kind of "checkpoint-fallback" capability that the client could use
> instead of this monstrous time-consuming practice. When talking
> thousands of updates in a batch, I'm not sure transactioning would be
> the best way to do it. That would be one big honking rollback.
> Thanks in advance to any of you architects out there!
>|||It is called a backup before you do any changes. Then if there is an issue
you simply restore.
Andrew J. Kelly SQL MVP
"BizEd" <EdMathias18@.gmail.com> wrote in message
news:1177351816.251254.221810@.b58g2000hsg.googlegroups.com...
>I have become involved with an assessment of a client's nightly update
> procedures, and I keep running into the following practice.
> The client consistently copies databases off to separate locations and
> performs updates upon the new copy. After successful update, the
> updated database is then copied back to the origin location and
> becomes the new version. All of this, obviously, to protect
> themselves in case of error. I can't help but suspect that SQL Server
> provides an easier way to do it.
> In the mainframe universe, this used to be accomplished via
> generational datasets which would be promoted as the baseline when the
> update completes. I guess what I'm asking is if SQL Server provides
> any kind of "checkpoint-fallback" capability that the client could use
> instead of this monstrous time-consuming practice. When talking
> thousands of updates in a batch, I'm not sure transactioning would be
> the best way to do it. That would be one big honking rollback.
> Thanks in advance to any of you architects out there!
>|||On Apr 23, 1:23 pm, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> SQL Server 2005 (Enterprise Edition) has, sort of, this. You can create a
"database snapshot"
> (CREATE DATABASE Copy AS SNAPSHOT OF Orig). The database files for the Cop
y database are initially
> empty and consume close to 0 disk space, i.e., the snapshot takes only a f
ew seconds to take. Then
> modify your Orig database. As you modify Orig database, the pages to be mo
dified are first copied to
> the Copy databases' database files. This way, the copy database always has
the data as it was when
> the snapshot was produced. If you need to "fall-back", then you can RESTOR
E DATABASE Orig FROM
> DATABASE_SNAPSHOT 'Copy', and all pages (in the Copy databases' database f
iles) are copied back to
> the Orig database' files and you are back where you began. Concept is call
ed "Copy on write".
> Same-same (concept) but different (implementation). :-)
> --
> Tibor Karaszi, SQL Server MVPhttp://www.karaszi.com/sqlserver/default.asph
ttp://sqlblog.com/blogs/tibor_karaszi
> "BizEd" <EdMathia...@.gmail.com> wrote in message
> news:1177351816.251254.221810@.b58g2000hsg.googlegroups.com...
>
>
>
>
>
> - Show quoted text -
Tibor,
Thanks. That's the type of functionality I was looking for. A simple
backup is not a sufficient solution when you are talking about a
multiple stage update process. If you wish to restart a step in the
process, the backup would necessitate going all the way back to the
beginning. Your solution is in essence "a delta file" which provides
functionality much more in line with the concept of mainframe
generational data sets!
Now to get the client on to SQL 2005....harrumph!|||Note that you can have several "delta-files" (several database snapshots). B
ut if you want to
restore from any of them, you need for first DROP DATABASE for all those sna
pshots except the one to
restore from.
Another important thing is that when you restore from a database snapshot, y
ou break the log backup
chain sequence for your database. So, if you are doing log backups for that
database, you want to do
a BACKUP DATABASE after restoring from a database snapshot.
And, as always, make sure you read all about this in Books Online first. :-)
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"BizEd" <EdMathias18@.gmail.com> wrote in message
news:1177365104.403457.180780@.b58g2000hsg.googlegroups.com...
> On Apr 23, 1:23 pm, "Tibor Karaszi"
> <tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> Tibor,
> Thanks. That's the type of functionality I was looking for. A simple
> backup is not a sufficient solution when you are talking about a
> multiple stage update process. If you wish to restart a step in the
> process, the backup would necessitate going all the way back to the
> beginning. Your solution is in essence "a delta file" which provides
> functionality much more in line with the concept of mainframe
> generational data sets!
> Now to get the client on to SQL 2005....harrumph!
>|||As a standard process, this seems excessive.
You are aware that within the processing, SQLServer (like most major
databases) allows you to define a transaction that holds off
commitment until all the steps have completed successfully, and can be
rolled back if any errors are detected?
Josh
On 23 Apr 2007 11:10:16 -0700, BizEd <EdMathias18@.gmail.com> wrote:

>I have become involved with an assessment of a client's nightly update
>procedures, and I keep running into the following practice.
>The client consistently copies databases off to separate locations and
>performs updates upon the new copy. After successful update, the
>updated database is then copied back to the origin location and
>becomes the new version. All of this, obviously, to protect
>themselves in case of error. I can't help but suspect that SQL Server
>provides an easier way to do it.
>In the mainframe universe, this used to be accomplished via
>generational datasets which would be promoted as the baseline when the
>update completes. I guess what I'm asking is if SQL Server provides
>any kind of "checkpoint-fallback" capability that the client could use
>instead of this monstrous time-consuming practice. When talking
>thousands of updates in a batch, I'm not sure transactioning would be
>the best way to do it. That would be one big honking rollback.
>Thanks in advance to any of you architects out there!

Nightly Update / Fallback protection

I have become involved with an assessment of a client's nightly update
procedures, and I keep running into the following practice.
The client consistently copies databases off to separate locations and
performs updates upon the new copy. After successful update, the
updated database is then copied back to the origin location and
becomes the new version. All of this, obviously, to protect
themselves in case of error. I can't help but suspect that SQL Server
provides an easier way to do it.
In the mainframe universe, this used to be accomplished via
generational datasets which would be promoted as the baseline when the
update completes. I guess what I'm asking is if SQL Server provides
any kind of "checkpoint-fallback" capability that the client could use
instead of this monstrous time-consuming practice. When talking
thousands of updates in a batch, I'm not sure transactioning would be
the best way to do it. That would be one big honking rollback.
Thanks in advance to any of you architects out there!SQL Server 2005 (Enterprise Edition) has, sort of, this. You can create a "database snapshot"
(CREATE DATABASE Copy AS SNAPSHOT OF Orig). The database files for the Copy database are initially
empty and consume close to 0 disk space, i.e., the snapshot takes only a few seconds to take. Then
modify your Orig database. As you modify Orig database, the pages to be modified are first copied to
the Copy databases' database files. This way, the copy database always has the data as it was when
the snapshot was produced. If you need to "fall-back", then you can RESTORE DATABASE Orig FROM
DATABASE_SNAPSHOT 'Copy', and all pages (in the Copy databases' database files) are copied back to
the Orig database' files and you are back where you began. Concept is called "Copy on write".
Same-same (concept) but different (implementation). :-)
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"BizEd" <EdMathias18@.gmail.com> wrote in message
news:1177351816.251254.221810@.b58g2000hsg.googlegroups.com...
>I have become involved with an assessment of a client's nightly update
> procedures, and I keep running into the following practice.
> The client consistently copies databases off to separate locations and
> performs updates upon the new copy. After successful update, the
> updated database is then copied back to the origin location and
> becomes the new version. All of this, obviously, to protect
> themselves in case of error. I can't help but suspect that SQL Server
> provides an easier way to do it.
> In the mainframe universe, this used to be accomplished via
> generational datasets which would be promoted as the baseline when the
> update completes. I guess what I'm asking is if SQL Server provides
> any kind of "checkpoint-fallback" capability that the client could use
> instead of this monstrous time-consuming practice. When talking
> thousands of updates in a batch, I'm not sure transactioning would be
> the best way to do it. That would be one big honking rollback.
> Thanks in advance to any of you architects out there!
>|||It is called a backup before you do any changes. Then if there is an issue
you simply restore.
--
Andrew J. Kelly SQL MVP
"BizEd" <EdMathias18@.gmail.com> wrote in message
news:1177351816.251254.221810@.b58g2000hsg.googlegroups.com...
>I have become involved with an assessment of a client's nightly update
> procedures, and I keep running into the following practice.
> The client consistently copies databases off to separate locations and
> performs updates upon the new copy. After successful update, the
> updated database is then copied back to the origin location and
> becomes the new version. All of this, obviously, to protect
> themselves in case of error. I can't help but suspect that SQL Server
> provides an easier way to do it.
> In the mainframe universe, this used to be accomplished via
> generational datasets which would be promoted as the baseline when the
> update completes. I guess what I'm asking is if SQL Server provides
> any kind of "checkpoint-fallback" capability that the client could use
> instead of this monstrous time-consuming practice. When talking
> thousands of updates in a batch, I'm not sure transactioning would be
> the best way to do it. That would be one big honking rollback.
> Thanks in advance to any of you architects out there!
>|||On Apr 23, 1:23 pm, "Tibor Karaszi"
<tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
> SQL Server 2005 (Enterprise Edition) has, sort of, this. You can create a "database snapshot"
> (CREATE DATABASE Copy AS SNAPSHOT OF Orig). The database files for the Copy database are initially
> empty and consume close to 0 disk space, i.e., the snapshot takes only a few seconds to take. Then
> modify your Orig database. As you modify Orig database, the pages to be modified are first copied to
> the Copy databases' database files. This way, the copy database always has the data as it was when
> the snapshot was produced. If you need to "fall-back", then you can RESTORE DATABASE Orig FROM
> DATABASE_SNAPSHOT 'Copy', and all pages (in the Copy databases' database files) are copied back to
> the Orig database' files and you are back where you began. Concept is called "Copy on write".
> Same-same (concept) but different (implementation). :-)
> --
> Tibor Karaszi, SQL Server MVPhttp://www.karaszi.com/sqlserver/default.asphttp://sqlblog.com/blogs/tibor_karaszi
> "BizEd" <EdMathia...@.gmail.com> wrote in message
> news:1177351816.251254.221810@.b58g2000hsg.googlegroups.com...
>
> >I have become involved with an assessment of a client's nightly update
> > procedures, and I keep running into the following practice.
> > The client consistently copies databases off to separate locations and
> > performs updates upon the new copy. After successful update, the
> > updated database is then copied back to the origin location and
> > becomes the new version. All of this, obviously, to protect
> > themselves in case of error. I can't help but suspect that SQL Server
> > provides an easier way to do it.
> > In the mainframe universe, this used to be accomplished via
> > generational datasets which would be promoted as the baseline when the
> > update completes. I guess what I'm asking is if SQL Server provides
> > any kind of "checkpoint-fallback" capability that the client could use
> > instead of this monstrous time-consuming practice. When talking
> > thousands of updates in a batch, I'm not sure transactioning would be
> > the best way to do it. That would be one big honking rollback.
> > Thanks in advance to any of you architects out there!- Hide quoted text -
> - Show quoted text -
Tibor,
Thanks. That's the type of functionality I was looking for. A simple
backup is not a sufficient solution when you are talking about a
multiple stage update process. If you wish to restart a step in the
process, the backup would necessitate going all the way back to the
beginning. Your solution is in essence "a delta file" which provides
functionality much more in line with the concept of mainframe
generational data sets!
Now to get the client on to SQL 2005....harrumph!|||Note that you can have several "delta-files" (several database snapshots). But if you want to
restore from any of them, you need for first DROP DATABASE for all those snapshots except the one to
restore from.
Another important thing is that when you restore from a database snapshot, you break the log backup
chain sequence for your database. So, if you are doing log backups for that database, you want to do
a BACKUP DATABASE after restoring from a database snapshot.
And, as always, make sure you read all about this in Books Online first. :-)
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"BizEd" <EdMathias18@.gmail.com> wrote in message
news:1177365104.403457.180780@.b58g2000hsg.googlegroups.com...
> On Apr 23, 1:23 pm, "Tibor Karaszi"
> <tibor_please.no.email_kara...@.hotmail.nomail.com> wrote:
>> SQL Server 2005 (Enterprise Edition) has, sort of, this. You can create a "database snapshot"
>> (CREATE DATABASE Copy AS SNAPSHOT OF Orig). The database files for the Copy database are
>> initially
>> empty and consume close to 0 disk space, i.e., the snapshot takes only a few seconds to take.
>> Then
>> modify your Orig database. As you modify Orig database, the pages to be modified are first copied
>> to
>> the Copy databases' database files. This way, the copy database always has the data as it was
>> when
>> the snapshot was produced. If you need to "fall-back", then you can RESTORE DATABASE Orig FROM
>> DATABASE_SNAPSHOT 'Copy', and all pages (in the Copy databases' database files) are copied back
>> to
>> the Orig database' files and you are back where you began. Concept is called "Copy on write".
>> Same-same (concept) but different (implementation). :-)
>> --
>> Tibor Karaszi, SQL Server
>> MVPhttp://www.karaszi.com/sqlserver/default.asphttp://sqlblog.com/blogs/tibor_karaszi
>> "BizEd" <EdMathia...@.gmail.com> wrote in message
>> news:1177351816.251254.221810@.b58g2000hsg.googlegroups.com...
>>
>> >I have become involved with an assessment of a client's nightly update
>> > procedures, and I keep running into the following practice.
>> > The client consistently copies databases off to separate locations and
>> > performs updates upon the new copy. After successful update, the
>> > updated database is then copied back to the origin location and
>> > becomes the new version. All of this, obviously, to protect
>> > themselves in case of error. I can't help but suspect that SQL Server
>> > provides an easier way to do it.
>> > In the mainframe universe, this used to be accomplished via
>> > generational datasets which would be promoted as the baseline when the
>> > update completes. I guess what I'm asking is if SQL Server provides
>> > any kind of "checkpoint-fallback" capability that the client could use
>> > instead of this monstrous time-consuming practice. When talking
>> > thousands of updates in a batch, I'm not sure transactioning would be
>> > the best way to do it. That would be one big honking rollback.
>> > Thanks in advance to any of you architects out there!- Hide quoted text -
>> - Show quoted text -
> Tibor,
> Thanks. That's the type of functionality I was looking for. A simple
> backup is not a sufficient solution when you are talking about a
> multiple stage update process. If you wish to restart a step in the
> process, the backup would necessitate going all the way back to the
> beginning. Your solution is in essence "a delta file" which provides
> functionality much more in line with the concept of mainframe
> generational data sets!
> Now to get the client on to SQL 2005....harrumph!
>|||As a standard process, this seems excessive.
You are aware that within the processing, SQLServer (like most major
databases) allows you to define a transaction that holds off
commitment until all the steps have completed successfully, and can be
rolled back if any errors are detected?
Josh
On 23 Apr 2007 11:10:16 -0700, BizEd <EdMathias18@.gmail.com> wrote:
>I have become involved with an assessment of a client's nightly update
>procedures, and I keep running into the following practice.
>The client consistently copies databases off to separate locations and
>performs updates upon the new copy. After successful update, the
>updated database is then copied back to the origin location and
>becomes the new version. All of this, obviously, to protect
>themselves in case of error. I can't help but suspect that SQL Server
>provides an easier way to do it.
>In the mainframe universe, this used to be accomplished via
>generational datasets which would be promoted as the baseline when the
>update completes. I guess what I'm asking is if SQL Server provides
>any kind of "checkpoint-fallback" capability that the client could use
>instead of this monstrous time-consuming practice. When talking
>thousands of updates in a batch, I'm not sure transactioning would be
>the best way to do it. That would be one big honking rollback.
>Thanks in advance to any of you architects out there!

Monday, February 20, 2012

Newbie: I don't understand user permissions for table access

I have a SQL Server database that has database userid/password protection.
When I open the database through EM I can add/delete/modify any table, but
when I look at the permissions for any of the tables there are NO options
set for any user of the database! I don't understand the purpose of the
permissions, I guess, since they don't have to be set in order to get access
to the tables.
TIA,
Larry Woodswrong
table permissions are important. They are required in order to
access/update/delete data.
HOW are you connecting to SQL Server?
NT Authentication?
SQL Server Authentication?
If SQL Server auth, what account are you using? sa? If so, that is the
"GOD" account. You have full permissions to do anything and everything.
If you are using NT auth, what rights does your NT account have? Is it
assigned server or database roles that allow the activities that you are
performing?
Finally, what rights/permissions have been granted to the PUBLIC role?
Often (unfortunately) companies simply grant all rights to the public
role...and then evey account (SQL and NT) inherit the rights assigned to the
public role. For obvious reasons this is a bad security model.
SQL Server has a strong security model and it works well when it is setup by
someone who knows what they are doing. In the wrong hands...
--
Keith
"Larry Woods" <larry@.NOSPAMlwoods.com> wrote in message
news:eM31J1KdEHA.3864@.TK2MSFTNGP10.phx.gbl...
> I have a SQL Server database that has database userid/password protection.
> When I open the database through EM I can add/delete/modify any table, but
> when I look at the permissions for any of the tables there are NO options
> set for any user of the database! I don't understand the purpose of the
> permissions, I guess, since they don't have to be set in order to get
access
> to the tables.
> TIA,
> Larry Woods
>|||My database is remote to my workstation. I am using EM on the workstation.
The database has a userid/password (not 'sa') but the userid has "public"
and "db_owner" roles. Does the "db_owner" have complete access to all
tables/fields WITHOUT specifying anything in the permissions dialogs?
My "public" role only has "SELECT" and "EXEC" permissions.
Thanks, again.
Larry Woods
And,
"Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in message
news:%23PTfc5KdEHA.3728@.TK2MSFTNGP09.phx.gbl...
> wrong
> table permissions are important. They are required in order to
> access/update/delete data.
> HOW are you connecting to SQL Server?
> NT Authentication?
> SQL Server Authentication?
> If SQL Server auth, what account are you using? sa? If so, that is the
> "GOD" account. You have full permissions to do anything and everything.
> If you are using NT auth, what rights does your NT account have? Is it
> assigned server or database roles that allow the activities that you are
> performing?
> Finally, what rights/permissions have been granted to the PUBLIC role?
> Often (unfortunately) companies simply grant all rights to the public
> role...and then evey account (SQL and NT) inherit the rights assigned to
the
> public role. For obvious reasons this is a bad security model.
> SQL Server has a strong security model and it works well when it is setup
by
> someone who knows what they are doing. In the wrong hands...
> --
> Keith
>
> "Larry Woods" <larry@.NOSPAMlwoods.com> wrote in message
> news:eM31J1KdEHA.3864@.TK2MSFTNGP10.phx.gbl...
> > I have a SQL Server database that has database userid/password
protection.
> > When I open the database through EM I can add/delete/modify any table,
but
> > when I look at the permissions for any of the tables there are NO
options
> > set for any user of the database! I don't understand the purpose of the
> > permissions, I guess, since they don't have to be set in order to get
> access
> > to the tables.
> >
> > TIA,
> >
> > Larry Woods
> >
> >
>|||Correct. The dbo_owner role allows you complete access to everything.
From Books Online
Roles
Fixed database role Description
db_owner Has all permissions in the database.
You can get to this page yourself. right-click on the Books Online icon in
your task bar. Select Jump to URL
enter the following:
mk:@.MSITStore:C:\Program%20Files\Microsoft%20SQL%20Server\80\Tools\Books\arc
hitec.chm::/8_ar_da_3xns.htm
--
Keith
"Larry Woods" <larry@.NOSPAMlwoods.com> wrote in message
news:uNv%23vFLdEHA.3380@.TK2MSFTNGP12.phx.gbl...
> My database is remote to my workstation. I am using EM on the
workstation.
> The database has a userid/password (not 'sa') but the userid has "public"
> and "db_owner" roles. Does the "db_owner" have complete access to all
> tables/fields WITHOUT specifying anything in the permissions dialogs?
> My "public" role only has "SELECT" and "EXEC" permissions.
> Thanks, again.
> Larry Woods
> And,
> "Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in message
> news:%23PTfc5KdEHA.3728@.TK2MSFTNGP09.phx.gbl...
> > wrong
> > table permissions are important. They are required in order to
> > access/update/delete data.
> >
> > HOW are you connecting to SQL Server?
> > NT Authentication?
> > SQL Server Authentication?
> >
> > If SQL Server auth, what account are you using? sa? If so, that is the
> > "GOD" account. You have full permissions to do anything and everything.
> >
> > If you are using NT auth, what rights does your NT account have? Is it
> > assigned server or database roles that allow the activities that you are
> > performing?
> >
> > Finally, what rights/permissions have been granted to the PUBLIC role?
> > Often (unfortunately) companies simply grant all rights to the public
> > role...and then evey account (SQL and NT) inherit the rights assigned to
> the
> > public role. For obvious reasons this is a bad security model.
> >
> > SQL Server has a strong security model and it works well when it is
setup
> by
> > someone who knows what they are doing. In the wrong hands...
> >
> > --
> > Keith
> >
> >
> > "Larry Woods" <larry@.NOSPAMlwoods.com> wrote in message
> > news:eM31J1KdEHA.3864@.TK2MSFTNGP10.phx.gbl...
> > > I have a SQL Server database that has database userid/password
> protection.
> > > When I open the database through EM I can add/delete/modify any table,
> but
> > > when I look at the permissions for any of the tables there are NO
> options
> > > set for any user of the database! I don't understand the purpose of
the
> > > permissions, I guess, since they don't have to be set in order to get
> > access
> > > to the tables.
> > >
> > > TIA,
> > >
> > > Larry Woods
> > >
> > >
> >
>|||Hi Larry,
ob_owner means you can do anything to that particular
database. If there are other databases you can attack to
then you may have different access rights.
I would sugest you have a look at
http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/architec/8_ar_da_8yur.asp and its sub
groups for a bit of background
Peter
MCDBA
>--Original Message--
>My database is remote to my workstation. I am using EM
on the workstation.
>The database has a userid/password (not 'sa') but the
userid has "public"
>and "db_owner" roles. Does the "db_owner" have complete
access to all
>tables/fields WITHOUT specifying anything in the
permissions dialogs?
>My "public" role only has "SELECT" and "EXEC" permissions.
>Thanks, again.
>Larry Woods
>And,
>"Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in
message
>news:%23PTfc5KdEHA.3728@.TK2MSFTNGP09.phx.gbl...
>> wrong
>> table permissions are important. They are required in
order to
>> access/update/delete data.
>> HOW are you connecting to SQL Server?
>> NT Authentication?
>> SQL Server Authentication?
>> If SQL Server auth, what account are you using? sa?
If so, that is the
>> "GOD" account. You have full permissions to do
anything and everything.
>> If you are using NT auth, what rights does your NT
account have? Is it
>> assigned server or database roles that allow the
activities that you are
>> performing?
>> Finally, what rights/permissions have been granted to
the PUBLIC role?
>> Often (unfortunately) companies simply grant all rights
to the public
>> role...and then evey account (SQL and NT) inherit the
rights assigned to
>the
>> public role. For obvious reasons this is a bad
security model.
>> SQL Server has a strong security model and it works
well when it is setup
>by
>> someone who knows what they are doing. In the wrong
hands...
>> --
>> Keith
>>
>> "Larry Woods" <larry@.NOSPAMlwoods.com> wrote in message
>> news:eM31J1KdEHA.3864@.TK2MSFTNGP10.phx.gbl...
>> > I have a SQL Server database that has database
userid/password
>protection.
>> > When I open the database through EM I can
add/delete/modify any table,
>but
>> > when I look at the permissions for any of the tables
there are NO
>options
>> > set for any user of the database! I don't understand
the purpose of the
>> > permissions, I guess, since they don't have to be set
in order to get
>> access
>> > to the tables.
>> >
>> > TIA,
>> >
>> > Larry Woods
>> >
>> >
>
>.
>|||Thanks for the quick response from all you guys. Now, tackle the other
email that I sent! ;-)
Why can I get to my SQL Server db tables through EM but NOT through a Access
project? In the Access project I can read/select any table in the database,
but no modify/add/delete capabilities.
''
Thanks, again.
Larry Woods
"Peter the Spate" <anonymous@.discussions.microsoft.com> wrote in message
news:5c1a01c474b4$b6cba070$a301280a@.phx.gbl...
> Hi Larry,
> ob_owner means you can do anything to that particular
> database. If there are other databases you can attack to
> then you may have different access rights.
> I would sugest you have a look at
> http://msdn.microsoft.com/library/default.asp?
> url=/library/en-us/architec/8_ar_da_8yur.asp and its sub
> groups for a bit of background
> Peter
> MCDBA
>
> >--Original Message--
> >My database is remote to my workstation. I am using EM
> on the workstation.
> >The database has a userid/password (not 'sa') but the
> userid has "public"
> >and "db_owner" roles. Does the "db_owner" have complete
> access to all
> >tables/fields WITHOUT specifying anything in the
> permissions dialogs?
> >
> >My "public" role only has "SELECT" and "EXEC" permissions.
> >
> >Thanks, again.
> >
> >Larry Woods
> >
> >And,
> >"Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in
> message
> >news:%23PTfc5KdEHA.3728@.TK2MSFTNGP09.phx.gbl...
> >> wrong
> >> table permissions are important. They are required in
> order to
> >> access/update/delete data.
> >>
> >> HOW are you connecting to SQL Server?
> >> NT Authentication?
> >> SQL Server Authentication?
> >>
> >> If SQL Server auth, what account are you using? sa?
> If so, that is the
> >> "GOD" account. You have full permissions to do
> anything and everything.
> >>
> >> If you are using NT auth, what rights does your NT
> account have? Is it
> >> assigned server or database roles that allow the
> activities that you are
> >> performing?
> >>
> >> Finally, what rights/permissions have been granted to
> the PUBLIC role?
> >> Often (unfortunately) companies simply grant all rights
> to the public
> >> role...and then evey account (SQL and NT) inherit the
> rights assigned to
> >the
> >> public role. For obvious reasons this is a bad
> security model.
> >>
> >> SQL Server has a strong security model and it works
> well when it is setup
> >by
> >> someone who knows what they are doing. In the wrong
> hands...
> >>
> >> --
> >> Keith
> >>
> >>
> >> "Larry Woods" <larry@.NOSPAMlwoods.com> wrote in message
> >> news:eM31J1KdEHA.3864@.TK2MSFTNGP10.phx.gbl...
> >> > I have a SQL Server database that has database
> userid/password
> >protection.
> >> > When I open the database through EM I can
> add/delete/modify any table,
> >but
> >> > when I look at the permissions for any of the tables
> there are NO
> >options
> >> > set for any user of the database! I don't understand
> the purpose of the
> >> > permissions, I guess, since they don't have to be set
> in order to get
> >> access
> >> > to the tables.
> >> >
> >> > TIA,
> >> >
> >> > Larry Woods
> >> >
> >> >
> >>
> >
> >
> >.
> >|||Probably because you do not have permissions in Access to
chenge the database, however in SQL Server you have
db_owner permission that does allow you to.
Peter
>--Original Message--
>Thanks for the quick response from all you guys. Now,
tackle the other
>email that I sent! ;-)
>Why can I get to my SQL Server db tables through EM but
NOT through a Access
>project? In the Access project I can read/select any
table in the database,
>but no modify/add/delete capabilities.
>''
>Thanks, again.
>Larry Woods
>"Peter the Spate" <anonymous@.discussions.microsoft.com>
wrote in message
>news:5c1a01c474b4$b6cba070$a301280a@.phx.gbl...
>> Hi Larry,
>> ob_owner means you can do anything to that particular
>> database. If there are other databases you can attack to
>> then you may have different access rights.
>> I would sugest you have a look at
>> http://msdn.microsoft.com/library/default.asp?
>> url=/library/en-us/architec/8_ar_da_8yur.asp and its sub
>> groups for a bit of background
>> Peter
>> MCDBA
>>
>> >--Original Message--
>> >My database is remote to my workstation. I am using EM
>> on the workstation.
>> >The database has a userid/password (not 'sa') but the
>> userid has "public"
>> >and "db_owner" roles. Does the "db_owner" have
complete
>> access to all
>> >tables/fields WITHOUT specifying anything in the
>> permissions dialogs?
>> >
>> >My "public" role only has "SELECT" and "EXEC"
permissions.
>> >
>> >Thanks, again.
>> >
>> >Larry Woods
>> >
>> >And,
>> >"Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in
>> message
>> >news:%23PTfc5KdEHA.3728@.TK2MSFTNGP09.phx.gbl...
>> >> wrong
>> >> table permissions are important. They are required
in
>> order to
>> >> access/update/delete data.
>> >>
>> >> HOW are you connecting to SQL Server?
>> >> NT Authentication?
>> >> SQL Server Authentication?
>> >>
>> >> If SQL Server auth, what account are you using? sa?
>> If so, that is the
>> >> "GOD" account. You have full permissions to do
>> anything and everything.
>> >>
>> >> If you are using NT auth, what rights does your NT
>> account have? Is it
>> >> assigned server or database roles that allow the
>> activities that you are
>> >> performing?
>> >>
>> >> Finally, what rights/permissions have been granted to
>> the PUBLIC role?
>> >> Often (unfortunately) companies simply grant all
rights
>> to the public
>> >> role...and then evey account (SQL and NT) inherit the
>> rights assigned to
>> >the
>> >> public role. For obvious reasons this is a bad
>> security model.
>> >>
>> >> SQL Server has a strong security model and it works
>> well when it is setup
>> >by
>> >> someone who knows what they are doing. In the wrong
>> hands...
>> >>
>> >> --
>> >> Keith
>> >>
>> >>
>> >> "Larry Woods" <larry@.NOSPAMlwoods.com> wrote in
message
>> >> news:eM31J1KdEHA.3864@.TK2MSFTNGP10.phx.gbl...
>> >> > I have a SQL Server database that has database
>> userid/password
>> >protection.
>> >> > When I open the database through EM I can
>> add/delete/modify any table,
>> >but
>> >> > when I look at the permissions for any of the
tables
>> there are NO
>> >options
>> >> > set for any user of the database! I don't
understand
>> the purpose of the
>> >> > permissions, I guess, since they don't have to be
set
>> in order to get
>> >> access
>> >> > to the tables.
>> >> >
>> >> > TIA,
>> >> >
>> >> > Larry Woods
>> >> >
>> >> >
>> >>
>> >
>> >
>> >.
>> >
>
>.
>|||Thanks, Peter.
That may be, but I can't find any place in Access where you can set
permissions.
Any suggestions?
Larry Woods
"Peter the Spate" <anonymous@.discussions.microsoft.com> wrote in message
news:5dfb01c474b8$6cc4d560$a501280a@.phx.gbl...
> Probably because you do not have permissions in Access to
> chenge the database, however in SQL Server you have
> db_owner permission that does allow you to.
> Peter
>
> >--Original Message--
> >Thanks for the quick response from all you guys. Now,
> tackle the other
> >email that I sent! ;-)
> >
> >Why can I get to my SQL Server db tables through EM but
> NOT through a Access
> >project? In the Access project I can read/select any
> table in the database,
> >but no modify/add/delete capabilities.
> >
> >''
> >
> >Thanks, again.
> >
> >Larry Woods
> >
> >"Peter the Spate" <anonymous@.discussions.microsoft.com>
> wrote in message
> >news:5c1a01c474b4$b6cba070$a301280a@.phx.gbl...
> >> Hi Larry,
> >>
> >> ob_owner means you can do anything to that particular
> >> database. If there are other databases you can attack to
> >> then you may have different access rights.
> >>
> >> I would sugest you have a look at
> >> http://msdn.microsoft.com/library/default.asp?
> >> url=/library/en-us/architec/8_ar_da_8yur.asp and its sub
> >> groups for a bit of background
> >>
> >> Peter
> >> MCDBA
> >>
> >>
> >> >--Original Message--
> >> >My database is remote to my workstation. I am using EM
> >> on the workstation.
> >> >The database has a userid/password (not 'sa') but the
> >> userid has "public"
> >> >and "db_owner" roles. Does the "db_owner" have
> complete
> >> access to all
> >> >tables/fields WITHOUT specifying anything in the
> >> permissions dialogs?
> >> >
> >> >My "public" role only has "SELECT" and "EXEC"
> permissions.
> >> >
> >> >Thanks, again.
> >> >
> >> >Larry Woods
> >> >
> >> >And,
> >> >"Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in
> >> message
> >> >news:%23PTfc5KdEHA.3728@.TK2MSFTNGP09.phx.gbl...
> >> >> wrong
> >> >> table permissions are important. They are required
> in
> >> order to
> >> >> access/update/delete data.
> >> >>
> >> >> HOW are you connecting to SQL Server?
> >> >> NT Authentication?
> >> >> SQL Server Authentication?
> >> >>
> >> >> If SQL Server auth, what account are you using? sa?
> >> If so, that is the
> >> >> "GOD" account. You have full permissions to do
> >> anything and everything.
> >> >>
> >> >> If you are using NT auth, what rights does your NT
> >> account have? Is it
> >> >> assigned server or database roles that allow the
> >> activities that you are
> >> >> performing?
> >> >>
> >> >> Finally, what rights/permissions have been granted to
> >> the PUBLIC role?
> >> >> Often (unfortunately) companies simply grant all
> rights
> >> to the public
> >> >> role...and then evey account (SQL and NT) inherit the
> >> rights assigned to
> >> >the
> >> >> public role. For obvious reasons this is a bad
> >> security model.
> >> >>
> >> >> SQL Server has a strong security model and it works
> >> well when it is setup
> >> >by
> >> >> someone who knows what they are doing. In the wrong
> >> hands...
> >> >>
> >> >> --
> >> >> Keith
> >> >>
> >> >>
> >> >> "Larry Woods" <larry@.NOSPAMlwoods.com> wrote in
> message
> >> >> news:eM31J1KdEHA.3864@.TK2MSFTNGP10.phx.gbl...
> >> >> > I have a SQL Server database that has database
> >> userid/password
> >> >protection.
> >> >> > When I open the database through EM I can
> >> add/delete/modify any table,
> >> >but
> >> >> > when I look at the permissions for any of the
> tables
> >> there are NO
> >> >options
> >> >> > set for any user of the database! I don't
> understand
> >> the purpose of the
> >> >> > permissions, I guess, since they don't have to be
> set
> >> in order to get
> >> >> access
> >> >> > to the tables.
> >> >> >
> >> >> > TIA,
> >> >> >
> >> >> > Larry Woods
> >> >> >
> >> >> >
> >> >>
> >> >
> >> >
> >> >.
> >> >
> >
> >
> >.
> >|||How do you link your tables? Try using a specific user that has the
appropriate permissions within SQL Server.
--
Keith
"Larry Woods" <larry@.NOSPAMlwoods.com> wrote in message
news:elv2x3LdEHA.3792@.TK2MSFTNGP09.phx.gbl...
> Thanks, Peter.
> That may be, but I can't find any place in Access where you can set
> permissions.
> Any suggestions?
> Larry Woods
> "Peter the Spate" <anonymous@.discussions.microsoft.com> wrote in message
> news:5dfb01c474b8$6cc4d560$a501280a@.phx.gbl...
> > Probably because you do not have permissions in Access to
> > chenge the database, however in SQL Server you have
> > db_owner permission that does allow you to.
> >
> > Peter
> >
> >
> > >--Original Message--
> > >Thanks for the quick response from all you guys. Now,
> > tackle the other
> > >email that I sent! ;-)
> > >
> > >Why can I get to my SQL Server db tables through EM but
> > NOT through a Access
> > >project? In the Access project I can read/select any
> > table in the database,
> > >but no modify/add/delete capabilities.
> > >
> > >''
> > >
> > >Thanks, again.
> > >
> > >Larry Woods
> > >
> > >"Peter the Spate" <anonymous@.discussions.microsoft.com>
> > wrote in message
> > >news:5c1a01c474b4$b6cba070$a301280a@.phx.gbl...
> > >> Hi Larry,
> > >>
> > >> ob_owner means you can do anything to that particular
> > >> database. If there are other databases you can attack to
> > >> then you may have different access rights.
> > >>
> > >> I would sugest you have a look at
> > >> http://msdn.microsoft.com/library/default.asp?
> > >> url=/library/en-us/architec/8_ar_da_8yur.asp and its sub
> > >> groups for a bit of background
> > >>
> > >> Peter
> > >> MCDBA
> > >>
> > >>
> > >> >--Original Message--
> > >> >My database is remote to my workstation. I am using EM
> > >> on the workstation.
> > >> >The database has a userid/password (not 'sa') but the
> > >> userid has "public"
> > >> >and "db_owner" roles. Does the "db_owner" have
> > complete
> > >> access to all
> > >> >tables/fields WITHOUT specifying anything in the
> > >> permissions dialogs?
> > >> >
> > >> >My "public" role only has "SELECT" and "EXEC"
> > permissions.
> > >> >
> > >> >Thanks, again.
> > >> >
> > >> >Larry Woods
> > >> >
> > >> >And,
> > >> >"Keith Kratochvil" <sqlguy.back2u@.comcast.net> wrote in
> > >> message
> > >> >news:%23PTfc5KdEHA.3728@.TK2MSFTNGP09.phx.gbl...
> > >> >> wrong
> > >> >> table permissions are important. They are required
> > in
> > >> order to
> > >> >> access/update/delete data.
> > >> >>
> > >> >> HOW are you connecting to SQL Server?
> > >> >> NT Authentication?
> > >> >> SQL Server Authentication?
> > >> >>
> > >> >> If SQL Server auth, what account are you using? sa?
> > >> If so, that is the
> > >> >> "GOD" account. You have full permissions to do
> > >> anything and everything.
> > >> >>
> > >> >> If you are using NT auth, what rights does your NT
> > >> account have? Is it
> > >> >> assigned server or database roles that allow the
> > >> activities that you are
> > >> >> performing?
> > >> >>
> > >> >> Finally, what rights/permissions have been granted to
> > >> the PUBLIC role?
> > >> >> Often (unfortunately) companies simply grant all
> > rights
> > >> to the public
> > >> >> role...and then evey account (SQL and NT) inherit the
> > >> rights assigned to
> > >> >the
> > >> >> public role. For obvious reasons this is a bad
> > >> security model.
> > >> >>
> > >> >> SQL Server has a strong security model and it works
> > >> well when it is setup
> > >> >by
> > >> >> someone who knows what they are doing. In the wrong
> > >> hands...
> > >> >>
> > >> >> --
> > >> >> Keith
> > >> >>
> > >> >>
> > >> >> "Larry Woods" <larry@.NOSPAMlwoods.com> wrote in
> > message
> > >> >> news:eM31J1KdEHA.3864@.TK2MSFTNGP10.phx.gbl...
> > >> >> > I have a SQL Server database that has database
> > >> userid/password
> > >> >protection.
> > >> >> > When I open the database through EM I can
> > >> add/delete/modify any table,
> > >> >but
> > >> >> > when I look at the permissions for any of the
> > tables
> > >> there are NO
> > >> >options
> > >> >> > set for any user of the database! I don't
> > understand
> > >> the purpose of the
> > >> >> > permissions, I guess, since they don't have to be
> > set
> > >> in order to get
> > >> >> access
> > >> >> > to the tables.
> > >> >> >
> > >> >> > TIA,
> > >> >> >
> > >> >> > Larry Woods
> > >> >> >
> > >> >> >
> > >> >>
> > >> >
> > >> >
> > >> >.
> > >> >
> > >
> > >
> > >.
> > >
>

Monday, March 19, 2012

Nightly Update / Fallback protection

Nightly Update / Fallback protection

Nightly Update / Fallback protection

Monday, February 20, 2012

Newbie: I don't understand user permissions for table access

Newbie: I don't understand user permissions for table access

Newbie: I don't understand user permissions for table access

Metadata Services

Blog Archive

About Me