Advice on DTS Package in Replication

Is it advicable to use DTS package as a tranformation media in transactional
replication or should transformation be done at Stored Procedure level on
Subscriber?
Under what circumstances it will be a good idea to use DTS package.
Thank you very much.
only use transformable subscription with hetergeneous subscribers. For SQL
Server subscribers there are other ways (stored procedures being one of
them) of transforming the data in route which offer far greater performance.
"Mark" <Mark@.discussions.microsoft.com> wrote in message
news:C9B7E873-C6A2-40CC-8EE5-0DAC1D1A7508@.microsoft.com...
> Is it advicable to use DTS package as a tranformation media in
> transactional
> replication or should transformation be done at Stored Procedure level on
> Subscriber?
> Under what circumstances it will be a good idea to use DTS package.
> Thank you very much.

Advantage of setting isolation level to READ UNCOMMITED

Hi,
I have two questions.
1) What is the advantage of setting isolation level to READ UNCOMMITED if
there are noupdates for the records that we are selecting?
Does it make the select faster when we don't issue any shared lock?
2) I found this statement in books online:
'if an update acquires a large number of row locks and has locked a
significant percentage of a table, the row locks are escalated to a table
lock'
Is this statement true when we have a select instead of update and isolation
level is READ COMMITED?
Thanks,
RosiePerformance is slightly better when using READ UNCOMMITTED for selects, as
SQL Server does not have to do any of the work of issuing shared locks.
And yes, SELECTs can escalate lock granularities.
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--
"Rosie" <Rosie@.discussions.microsoft.com> wrote in message
news:2E0888C6-59F0-4E52-B4C8-2D91645D1FDB@.microsoft.com...
> Hi,
> I have two questions.
> 1) What is the advantage of setting isolation level to READ UNCOMMITED if
> there are noupdates for the records that we are selecting?
> Does it make the select faster when we don't issue any shared lock?
> 2) I found this statement in books online:
> 'if an update acquires a large number of row locks and has locked a
> significant percentage of a table, the row locks are escalated to a table
> lock'
> Is this statement true when we have a select instead of update and
isolation
> level is READ COMMITED?
> Thanks,
> Rosie|||> 1) What is the advantage of setting isolation level to READ UNCOMMITED if
> there are noupdates for the records that we are selecting?
> Does it make the select faster when we don't issue any shared lock?
Sure, since there is less work to do. Will it make it that much faster, not
really unless the statement would have been blocked.

> 2) I found this statement in books online:
> 'if an update acquires a large number of row locks and has locked a
> significant percentage of a table, the row locks are escalated to a table
> lock'
> Is this statement true when we have a select instead of update and
> isolation
> level is READ COMMITED?
If you are in read committed isolation level, then you would not escalate.
Basically, as rows are fetched a lock is taken on that row. Then the row is
placed on the output buffer, the lock is released, a new row is locked and
fetched, etc. So only one row should be locked during the select. The
holdup comes when the single row that need to be locked is already locked.
Then wait city. If you are doing lots of updates, or in READ COMMITTED or
SERIALIZABLE transaction isolation level, then the table lock might come in
to play, but you would likely have to lock a lot of rows.
----
Louis Davidson - drsql@.hotmail.com
SQL Server MVP
Compass Technology Management - www.compass.net
Pro SQL Server 2000 Database Design -
http://www.apress.com/book/bookDisplay.html?bID=266
Note: Please reply to the newsgroups only unless you are interested in
consulting services. All other replies may be ignored :)
"Rosie" <Rosie@.discussions.microsoft.com> wrote in message
news:2E0888C6-59F0-4E52-B4C8-2D91645D1FDB@.microsoft.com...
> Hi,
> I have two questions.
> 1) What is the advantage of setting isolation level to READ UNCOMMITED if
> there are noupdates for the records that we are selecting?
> Does it make the select faster when we don't issue any shared lock?
> 2) I found this statement in books online:
> 'if an update acquires a large number of row locks and has locked a
> significant percentage of a table, the row locks are escalated to a table
> lock'
> Is this statement true when we have a select instead of update and
> isolation
> level is READ COMMITED?
> Thanks,
> Rosie

Admin access to SQL without server/domain admin access

We are using Win2k3 R2 with SQL 2000 in a domain environment.

Is it possible to create a domain group to grant admin level and user level access to SQL2000/2005 without giving users server admin or domain admin access?

It has always been my impression that to have admin access to SQL that you had to at least had admin level access on the server.

Any clarification would be greatly appreciated.

Thanks!

Part of the problem may be from using a more generic phrase like "admin level access to SQL". What that means to you, I'm not sure. That could be interpreted as administering the server from the windows level or it could mean being a member of the sysadmins server role in SQL Server.

But you don't need to be a member of a windows windows administrator group (local administrator on the server or domain administrator in the domain) to be a member of the sysamin server role in SQL Server. A member of the sysadmin role in SQL Server can add other logins to the sysadmin role - and anything thing else they want to do as members of the sysadmins role bypass security checks and can do anything in SQL Server. This is what it sounds like you are asking about.

I have seen some similar confusion coming from this type of scenario:

You have your SQL Server running under a service account and that account is a member of the local administrators group on the server on which SQL Server is running

You are a member of the sysadmin server role in SQL Server

Some of the command you execute as a member of the sysadmin role will execute under the security context of the service account. Being that the service account is a member of the local administrators group, you are executing some of the commands as if you are a member of the local administrators group on that server.

But that scenario doesn't mean you are a member of the local administrators group or that you need to be a member of the local administrators group.

-Sue