Power user question

I want to create a user on SQL Server 2005 that needs to be able to
create databases, logins, and users, as well as create stored procs,
triggers, tables, etc. This user will be accessed from a vb.net
application. Is there anything less powerful than the 'sa' user that
will do the trick, or some kind of roll-my-own permissions? I really
haven't played around too much with assigning SQL Server permissions
before.
Cheers,
MarcusYou can grant the server role Database Creators to the user, and then grant
the fixed database role db_ddladmin for each existing database.
"Marcus" wrote:

> I want to create a user on SQL Server 2005 that needs to be able to
> create databases, logins, and users, as well as create stored procs,
> triggers, tables, etc. This user will be accessed from a vb.net
> application. Is there anything less powerful than the 'sa' user that
> will do the trick, or some kind of roll-my-own permissions? I really
> haven't played around too much with assigning SQL Server permissions
> before.
> Cheers,
> Marcus
>

Power user question

I want to create a user on SQL Server 2005 that needs to be able to
create databases, logins, and users, as well as create stored procs,
triggers, tables, etc. This user will be accessed from a vb.net
application. Is there anything less powerful than the 'sa' user that
will do the trick, or some kind of roll-my-own permissions? I really
haven't played around too much with assigning SQL Server permissions
before.
Cheers,
MarcusYou can grant the server role Database Creators to the user, and then grant
the fixed database role db_ddladmin for each existing database.
"Marcus" wrote:
> I want to create a user on SQL Server 2005 that needs to be able to
> create databases, logins, and users, as well as create stored procs,
> triggers, tables, etc. This user will be accessed from a vb.net
> application. Is there anything less powerful than the 'sa' user that
> will do the trick, or some kind of roll-my-own permissions? I really
> haven't played around too much with assigning SQL Server permissions
> before.
> Cheers,
> Marcus
>

Power Failure for SQL Server 2000

We encounter a power failure for about half an hour and
the SQL Server 2000 is back again.
For production databases, we use FULL Recovery Model with
Transaction Log backed up every half an hour. After power
is up, everything works properly.
I would like to know what happens to the SQL Server 2000
when the power fails and how the data is recovered when
power is up again.
ThanksRegardless of the recovery model, each database is automatically recovered
when the instance starts. Data are read from the transaction log since the
last checkpoint and applied to the database. Uncommitted transactions are
then rolled back. The end result is that the database is recovered to the
point of the failure, less uncommitted transactions.
Your FULL recovery model and log backups provide extra protection in the
event of media loss due to hardware failure or data corruption.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Peter" <anonymous@.discussions.microsoft.com> wrote in message
news:01f401c5446e$a4183b70$a601280a@.phx.gbl...
> We encounter a power failure for about half an hour and
> the SQL Server 2000 is back again.
> For production databases, we use FULL Recovery Model with
> Transaction Log backed up every half an hour. After power
> is up, everything works properly.
> I would like to know what happens to the SQL Server 2000
> when the power fails and how the data is recovered when
> power is up again.
> Thanks|||Dear Dan,
Thank you for your advice.
However, for SIMPLE Recovery Model, there will be no
transaction log backup. To what state does the database
recovered to ?
Besides, would you mind to elaborate on the extra benefit
of using FULL Recovery Model ?
Thanks again.
>--Original Message--
>Regardless of the recovery model, each database is
automatically recovered
>when the instance starts. Data are read from the
transaction log since the
>last checkpoint and applied to the database. Uncommitted
transactions are
>then rolled back. The end result is that the database is
recovered to the
>point of the failure, less uncommitted transactions.
>Your FULL recovery model and log backups provide extra
protection in the
>event of media loss due to hardware failure or data
corruption.
>--
>Hope this helps.
>Dan Guzman
>SQL Server MVP
>"Peter" <anonymous@.discussions.microsoft.com> wrote in
message
>news:01f401c5446e$a4183b70$a601280a@.phx.gbl...
>> We encounter a power failure for about half an hour and
>> the SQL Server 2000 is back again.
>> For production databases, we use FULL Recovery Model
with
>> Transaction Log backed up every half an hour. After
power
>> is up, everything works properly.
>> I would like to know what happens to the SQL Server 2000
>> when the power fails and how the data is recovered when
>> power is up again.
>> Thanks
>
>.
>|||Peter
<http://vyaskn.tripod.com/sql_server_administration_best_practices.htm#Step1
> --administaiting best practices
"Peter" <anonymous@.discussions.microsoft.com> wrote in message
news:077101c54475$9661ee70$a501280a@.phx.gbl...
> Dear Dan,
> Thank you for your advice.
> However, for SIMPLE Recovery Model, there will be no
> transaction log backup. To what state does the database
> recovered to ?
> Besides, would you mind to elaborate on the extra benefit
> of using FULL Recovery Model ?
> Thanks again.
> >--Original Message--
> >Regardless of the recovery model, each database is
> automatically recovered
> >when the instance starts. Data are read from the
> transaction log since the
> >last checkpoint and applied to the database. Uncommitted
> transactions are
> >then rolled back. The end result is that the database is
> recovered to the
> >point of the failure, less uncommitted transactions.
> >
> >Your FULL recovery model and log backups provide extra
> protection in the
> >event of media loss due to hardware failure or data
> corruption.
> >
> >--
> >Hope this helps.
> >
> >Dan Guzman
> >SQL Server MVP
> >
> >"Peter" <anonymous@.discussions.microsoft.com> wrote in
> message
> >news:01f401c5446e$a4183b70$a601280a@.phx.gbl...
> >> We encounter a power failure for about half an hour and
> >> the SQL Server 2000 is back again.
> >>
> >> For production databases, we use FULL Recovery Model
> with
> >> Transaction Log backed up every half an hour. After
> power
> >> is up, everything works properly.
> >>
> >> I would like to know what happens to the SQL Server 2000
> >> when the power fails and how the data is recovered when
> >> power is up again.
> >>
> >> Thanks
> >
> >
> >.
> >|||Automatic recovery (what happens when you start SQL Server) doesn't have anything to do with
backups. SQL Server records all modifications in the transaction log, regardless of recovery model.
In simple, SQL Server removes log records from the transaction log when they aren't needed anymore
for this automatic recovery.
Full recovery model allow you to backup transaction log. This has a lot of advantages, like backup
log even of the database becomes corrupt, point in time restore etc.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Peter" <anonymous@.discussions.microsoft.com> wrote in message
news:077101c54475$9661ee70$a501280a@.phx.gbl...
> Dear Dan,
> Thank you for your advice.
> However, for SIMPLE Recovery Model, there will be no
> transaction log backup. To what state does the database
> recovered to ?
> Besides, would you mind to elaborate on the extra benefit
> of using FULL Recovery Model ?
> Thanks again.
>>--Original Message--
>>Regardless of the recovery model, each database is
> automatically recovered
>>when the instance starts. Data are read from the
> transaction log since the
>>last checkpoint and applied to the database. Uncommitted
> transactions are
>>then rolled back. The end result is that the database is
> recovered to the
>>point of the failure, less uncommitted transactions.
>>Your FULL recovery model and log backups provide extra
> protection in the
>>event of media loss due to hardware failure or data
> corruption.
>>--
>>Hope this helps.
>>Dan Guzman
>>SQL Server MVP
>>"Peter" <anonymous@.discussions.microsoft.com> wrote in
> message
>>news:01f401c5446e$a4183b70$a601280a@.phx.gbl...
>> We encounter a power failure for about half an hour and
>> the SQL Server 2000 is back again.
>> For production databases, we use FULL Recovery Model
> with
>> Transaction Log backed up every half an hour. After
> power
>> is up, everything works properly.
>> I would like to know what happens to the SQL Server 2000
>> when the power fails and how the data is recovered when
>> power is up again.
>> Thanks
>>
>>.|||To add to the other responses, automatic recovery will recover databases to
the same consistent state regardless of the recovery model.
Separately, database and transaction log backups reduce your vulnerability
to potential data loss. For example, if your power outage caused a hardware
problem that corrupted your log file, you could still restore from your most
recent database backup and then apply your log backups. At most, you would
lose one half hour of work. If only data files were lost, you could backup
the current log with NO_TRUNCATE and then restore your database and log
backups. No data would be lost in this case.
In the SIMPLE recovery model, your only recourse after losing data or log
files is to restore from your most recent database backup. All data
modifications since the backup would be lost.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Peter" <anonymous@.discussions.microsoft.com> wrote in message
news:077101c54475$9661ee70$a501280a@.phx.gbl...
> Dear Dan,
> Thank you for your advice.
> However, for SIMPLE Recovery Model, there will be no
> transaction log backup. To what state does the database
> recovered to ?
> Besides, would you mind to elaborate on the extra benefit
> of using FULL Recovery Model ?
> Thanks again.
>>--Original Message--
>>Regardless of the recovery model, each database is
> automatically recovered
>>when the instance starts. Data are read from the
> transaction log since the
>>last checkpoint and applied to the database. Uncommitted
> transactions are
>>then rolled back. The end result is that the database is
> recovered to the
>>point of the failure, less uncommitted transactions.
>>Your FULL recovery model and log backups provide extra
> protection in the
>>event of media loss due to hardware failure or data
> corruption.
>>--
>>Hope this helps.
>>Dan Guzman
>>SQL Server MVP
>>"Peter" <anonymous@.discussions.microsoft.com> wrote in
> message
>>news:01f401c5446e$a4183b70$a601280a@.phx.gbl...
>> We encounter a power failure for about half an hour and
>> the SQL Server 2000 is back again.
>> For production databases, we use FULL Recovery Model
> with
>> Transaction Log backed up every half an hour. After
> power
>> is up, everything works properly.
>> I would like to know what happens to the SQL Server 2000
>> when the power fails and how the data is recovered when
>> power is up again.
>> Thanks
>>
>>.

Power Failure for SQL Server 2000

We encounter a power failure for about half an hour and
the SQL Server 2000 is back again.
For production databases, we use FULL Recovery Model with
Transaction Log backed up every half an hour. After power
is up, everything works properly.
I would like to know what happens to the SQL Server 2000
when the power fails and how the data is recovered when
power is up again.
Thanks
Regardless of the recovery model, each database is automatically recovered
when the instance starts. Data are read from the transaction log since the
last checkpoint and applied to the database. Uncommitted transactions are
then rolled back. The end result is that the database is recovered to the
point of the failure, less uncommitted transactions.
Your FULL recovery model and log backups provide extra protection in the
event of media loss due to hardware failure or data corruption.
Hope this helps.
Dan Guzman
SQL Server MVP
"Peter" <anonymous@.discussions.microsoft.com> wrote in message
news:01f401c5446e$a4183b70$a601280a@.phx.gbl...
> We encounter a power failure for about half an hour and
> the SQL Server 2000 is back again.
> For production databases, we use FULL Recovery Model with
> Transaction Log backed up every half an hour. After power
> is up, everything works properly.
> I would like to know what happens to the SQL Server 2000
> when the power fails and how the data is recovered when
> power is up again.
> Thanks
|||Dear Dan,
Thank you for your advice.
However, for SIMPLE Recovery Model, there will be no
transaction log backup. To what state does the database
recovered to ?
Besides, would you mind to elaborate on the extra benefit
of using FULL Recovery Model ?
Thanks again.

>--Original Message--
>Regardless of the recovery model, each database is
automatically recovered
>when the instance starts. Data are read from the
transaction log since the
>last checkpoint and applied to the database. Uncommitted
transactions are
>then rolled back. The end result is that the database is
recovered to the
>point of the failure, less uncommitted transactions.
>Your FULL recovery model and log backups provide extra
protection in the
>event of media loss due to hardware failure or data
corruption.
>--
>Hope this helps.
>Dan Guzman
>SQL Server MVP
>"Peter" <anonymous@.discussions.microsoft.com> wrote in
message[vbcol=seagreen]
>news:01f401c5446e$a4183b70$a601280a@.phx.gbl...
with[vbcol=seagreen]
power
>
>.
>
|||Peter
<http://vyaskn.tripod.com/sql_server_...ices.htm#Step1
> --administaiting best practices
"Peter" <anonymous@.discussions.microsoft.com> wrote in message
news:077101c54475$9661ee70$a501280a@.phx.gbl...[vbcol=seagreen]
> Dear Dan,
> Thank you for your advice.
> However, for SIMPLE Recovery Model, there will be no
> transaction log backup. To what state does the database
> recovered to ?
> Besides, would you mind to elaborate on the extra benefit
> of using FULL Recovery Model ?
> Thanks again.
> automatically recovered
> transaction log since the
> transactions are
> recovered to the
> protection in the
> corruption.
> message
> with
> power
|||Automatic recovery (what happens when you start SQL Server) doesn't have anything to do with
backups. SQL Server records all modifications in the transaction log, regardless of recovery model.
In simple, SQL Server removes log records from the transaction log when they aren't needed anymore
for this automatic recovery.
Full recovery model allow you to backup transaction log. This has a lot of advantages, like backup
log even of the database becomes corrupt, point in time restore etc.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Peter" <anonymous@.discussions.microsoft.com> wrote in message
news:077101c54475$9661ee70$a501280a@.phx.gbl...[vbcol=seagreen]
> Dear Dan,
> Thank you for your advice.
> However, for SIMPLE Recovery Model, there will be no
> transaction log backup. To what state does the database
> recovered to ?
> Besides, would you mind to elaborate on the extra benefit
> of using FULL Recovery Model ?
> Thanks again.
> automatically recovered
> transaction log since the
> transactions are
> recovered to the
> protection in the
> corruption.
> message
> with
> power
|||To add to the other responses, automatic recovery will recover databases to
the same consistent state regardless of the recovery model.
Separately, database and transaction log backups reduce your vulnerability
to potential data loss. For example, if your power outage caused a hardware
problem that corrupted your log file, you could still restore from your most
recent database backup and then apply your log backups. At most, you would
lose one half hour of work. If only data files were lost, you could backup
the current log with NO_TRUNCATE and then restore your database and log
backups. No data would be lost in this case.
In the SIMPLE recovery model, your only recourse after losing data or log
files is to restore from your most recent database backup. All data
modifications since the backup would be lost.
Hope this helps.
Dan Guzman
SQL Server MVP
"Peter" <anonymous@.discussions.microsoft.com> wrote in message
news:077101c54475$9661ee70$a501280a@.phx.gbl...[vbcol=seagreen]
> Dear Dan,
> Thank you for your advice.
> However, for SIMPLE Recovery Model, there will be no
> transaction log backup. To what state does the database
> recovered to ?
> Besides, would you mind to elaborate on the extra benefit
> of using FULL Recovery Model ?
> Thanks again.
> automatically recovered
> transaction log since the
> transactions are
> recovered to the
> protection in the
> corruption.
> message
> with
> power

Power Failure for SQL Server 2000

We encounter a power failure for about half an hour and
the SQL Server 2000 is back again.
For production databases, we use FULL Recovery Model with
Transaction Log backed up every half an hour. After power
is up, everything works properly.
I would like to know what happens to the SQL Server 2000
when the power fails and how the data is recovered when
power is up again.
ThanksRegardless of the recovery model, each database is automatically recovered
when the instance starts. Data are read from the transaction log since the
last checkpoint and applied to the database. Uncommitted transactions are
then rolled back. The end result is that the database is recovered to the
point of the failure, less uncommitted transactions.
Your FULL recovery model and log backups provide extra protection in the
event of media loss due to hardware failure or data corruption.
Hope this helps.
Dan Guzman
SQL Server MVP
"Peter" <anonymous@.discussions.microsoft.com> wrote in message
news:01f401c5446e$a4183b70$a601280a@.phx.gbl...
> We encounter a power failure for about half an hour and
> the SQL Server 2000 is back again.
> For production databases, we use FULL Recovery Model with
> Transaction Log backed up every half an hour. After power
> is up, everything works properly.
> I would like to know what happens to the SQL Server 2000
> when the power fails and how the data is recovered when
> power is up again.
> Thanks|||Dear Dan,
Thank you for your advice.
However, for SIMPLE Recovery Model, there will be no
transaction log backup. To what state does the database
recovered to ?
Besides, would you mind to elaborate on the extra benefit
of using FULL Recovery Model ?
Thanks again.

>--Original Message--
>Regardless of the recovery model, each database is
automatically recovered
>when the instance starts. Data are read from the
transaction log since the
>last checkpoint and applied to the database. Uncommitted
transactions are
>then rolled back. The end result is that the database is
recovered to the
>point of the failure, less uncommitted transactions.
>Your FULL recovery model and log backups provide extra
protection in the
>event of media loss due to hardware failure or data
corruption.
>--
>Hope this helps.
>Dan Guzman
>SQL Server MVP
>"Peter" <anonymous@.discussions.microsoft.com> wrote in
message
>news:01f401c5446e$a4183b70$a601280a@.phx.gbl...
with[vbcol=seagreen]
power[vbcol=seagreen]
>
>.
>|||Peter
<.htm#Step1" target="_blank">http://vyaskn.tripod.com/ sql_serve...r />
.htm#Step1
> --administaiting best practices
"Peter" <anonymous@.discussions.microsoft.com> wrote in message
news:077101c54475$9661ee70$a501280a@.phx.gbl...[vbcol=seagreen]
> Dear Dan,
> Thank you for your advice.
> However, for SIMPLE Recovery Model, there will be no
> transaction log backup. To what state does the database
> recovered to ?
> Besides, would you mind to elaborate on the extra benefit
> of using FULL Recovery Model ?
> Thanks again.
>
> automatically recovered
> transaction log since the
> transactions are
> recovered to the
> protection in the
> corruption.
> message
> with
> power|||Automatic recovery (what happens when you start SQL Server) doesn't have any
thing to do with
backups. SQL Server records all modifications in the transaction log, regard
less of recovery model.
In simple, SQL Server removes log records from the transaction log when they
aren't needed anymore
for this automatic recovery.
Full recovery model allow you to backup transaction log. This has a lot of a
dvantages, like backup
log even of the database becomes corrupt, point in time restore etc.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Peter" <anonymous@.discussions.microsoft.com> wrote in message
news:077101c54475$9661ee70$a501280a@.phx.gbl...[vbcol=seagreen]
> Dear Dan,
> Thank you for your advice.
> However, for SIMPLE Recovery Model, there will be no
> transaction log backup. To what state does the database
> recovered to ?
> Besides, would you mind to elaborate on the extra benefit
> of using FULL Recovery Model ?
> Thanks again.
>
> automatically recovered
> transaction log since the
> transactions are
> recovered to the
> protection in the
> corruption.
> message
> with
> power|||To add to the other responses, automatic recovery will recover databases to
the same consistent state regardless of the recovery model.
Separately, database and transaction log backups reduce your vulnerability
to potential data loss. For example, if your power outage caused a hardware
problem that corrupted your log file, you could still restore from your most
recent database backup and then apply your log backups. At most, you would
lose one half hour of work. If only data files were lost, you could backup
the current log with NO_TRUNCATE and then restore your database and log
backups. No data would be lost in this case.
In the SIMPLE recovery model, your only recourse after losing data or log
files is to restore from your most recent database backup. All data
modifications since the backup would be lost.
Hope this helps.
Dan Guzman
SQL Server MVP
"Peter" <anonymous@.discussions.microsoft.com> wrote in message
news:077101c54475$9661ee70$a501280a@.phx.gbl...[vbcol=seagreen]
> Dear Dan,
> Thank you for your advice.
> However, for SIMPLE Recovery Model, there will be no
> transaction log backup. To what state does the database
> recovered to ?
> Besides, would you mind to elaborate on the extra benefit
> of using FULL Recovery Model ?
> Thanks again.
>
> automatically recovered
> transaction log since the
> transactions are
> recovered to the
> protection in the
> corruption.
> message
> with
> power

Potential issue with DTS and Log Shipping

Hi everyone.

I have a question that maybe some of you may be able to shed some light
on. My set up involves three SQL Server Databases. First one, used by
the application. Second, copy of first via log shipping. Third,
contains data aggregation from the Second. Now, my issue is that I
have a DTS packagage that (COPY SQL SERVER OBJECTS) that copys select
tables from the second DB, into the third. The issue lies when the DTS
package executes, everyonce in a while it errors out. I'm assuming
it's an error due to the log shipping restore on the second database.
Are there any solutions to this?

TIA<guevara_81@.yahoo.com> wrote in message
news:1104855148.496261.221680@.z14g2000cwz.googlegr oups.com...
> Hi everyone.
> I have a question that maybe some of you may be able to shed some light
> on. My set up involves three SQL Server Databases. First one, used by
> the application. Second, copy of first via log shipping. Third,
> contains data aggregation from the Second. Now, my issue is that I
> have a DTS packagage that (COPY SQL SERVER OBJECTS) that copys select
> tables from the second DB, into the third. The issue lies when the DTS
> package executes, everyonce in a while it errors out. I'm assuming
> it's an error due to the log shipping restore on the second database.
> Are there any solutions to this?
> TIA

One possible solution could be to check DATABASEPROPERTYEX('MyDB', 'Status')
either before executing the package or within the package itself - if it
isn't online then you can wait for an appropriate period of time and try
again.

Simon|||Thanks! That's a HUGE help.

thanks again.

-A

Post-Relational Databases

I just recently came across Post-Relational databases, strange I never heard
of them before. Anyone any experience of them, are they going to be the next
generation of databases as I heard one guy claim!?
Thanks
NYes, that old dilemma - is reality made up of relations or objects? :)
ML
http://milambda.blogspot.com/|||So its just an OO Database. I'm a relational man myself!
"NH" wrote:

> I just recently came across Post-Relational databases, strange I never hea
rd
> of them before. Anyone any experience of them, are they going to be the ne
xt
> generation of databases as I heard one guy claim!?
> Thanks
> N|||I thought we realted objects in the relational database :)
"ML" wrote:

> Yes, that old dilemma - is reality made up of relations or objects? :)
>
> ML
> --
> http://milambda.blogspot.com/|||ML wrote:
> Yes, that old dilemma - is reality made up of relations or objects? :)
>
Neither. Both are abstractions. What does "post-relational" mean to
you?
More appropriate for comp.databases.theory anyway.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||> Neither. Both are abstractions.
Absolutely. No argument there.

> What does "post-relational" mean to you?
Seriously? Well, no offense indended but the first time I heard this
expression I thought it had to do with divorce. Maybe even a weird
puritanistic definition of the state two (or more) sexual partners are in
after sexual intercourse.
ML
http://milambda.blogspot.com/|||"ML" <ML@.discussions.microsoft.com> wrote in message
news:9E68AE41-2414-4B49-A8BE-FC078B2D4BA8@.microsoft.com...
> Absolutely. No argument there.
>
> Seriously? Well, no offense indended but the first time I heard this
> expression I thought it had to do with divorce. Maybe even a weird
> puritanistic definition of the state two (or more) sexual partners are in
> after sexual intercourse.
>
> ML
> --
> http://milambda.blogspot.com/
I get it. NH's posts didn't show up at first so I thought you started the
thread.
Post-relational is what XML fans call the hierachical model. The rest of us
call it Pre-Relational.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx|||A brief look at Matisse (for example) gives the impression of another layer
of abstraction on top of a "regular" relational model.
Sometimes abstraction is good, but sooner or later...
abstraction = confusion
ML
http://milambda.blogspot.com/|||> Post-relational is what XML fans call the hierachical model. The rest of us call it[color
=darkred]
> Pre-Relational.[/color]
LOL!
That's a classic.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:es6j0GzfGHA.5092@.TK2MSFTNGP04.phx.gbl...
> "ML" <ML@.discussions.microsoft.com> wrote in message
> news:9E68AE41-2414-4B49-A8BE-FC078B2D4BA8@.microsoft.com...
> I get it. NH's posts didn't show up at first so I thought you started the
thread.
> Post-relational is what XML fans call the hierachical model. The rest of u
s call it
> Pre-Relational.
> --
> David Portas, SQL Server MVP
> Whenever possible please post enough code to reproduce your problem.
> Including CREATE TABLE and INSERT statements usually helps.
> State what version of SQL Server you are using and specify the content
> of any error messages.
> SQL Server Books Online:
> http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
> --
>
>|||"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:1148473208.702352.33010@.g10g2000cwb.googlegroups.com...
> More appropriate for comp.databases.theory anyway.
Yup. We never get into theory in this forum.
=P

Post Hotfix error

I am getting the following (MOM) error on 3 of my databases anytime I initiate a backup of the mdf. The database seems to backup as expected. The one thing that has recently changed is I implemented MS Hotfix 2187 on my SQl cluster over the weekend.

Severity: Critical Error

Status: New

Source: MSSQLSERVER

Name: Commit record has already been distributed. Check DBTABLE

Description: Unable to expand message 17055 [-1073724769] 18264 Database backed up: Database: XX03PLUS, creation date(time): 2005/12/06(18:38:50), pages dumped: 23026, first LSN: 18761:44:1, last LSN: 18761:46:1, number of dump devices: 1, device information: (FILE=1, TYPE=DISK: {'G:\temp\ar03PLUS_fromVCforK1.bak'}).

thanks in advance,

Jerry

I thought I would reply to my own post as I have remediated the error in case someone else ever has this issue.

AS it turns out the Hotfix 'upgrade' can create orphaned users and or users with 'not as expected' permissions. By deinstalling (detaching) and reinstalling (re-attaching) via an internal script that also reassigned appropriate users and permissions I wa able to clean up the errors.

best of luck,

Jerry

Possible to restrict which dbs are shown in Management Studio...

Hi,
I'm migrating a load of databases from a SQL 2000 server to SQL 2005 and was
wondering if anyone knew how to restrict the list of databases that users
see when they connect using the Management Studio to only those that they
have access to? This was done in SQL 2000 by using the following:
http://support.microsoft.com/default.aspx/kb/889696
Any help is appreciated.
Thanks - Joe.In 2005, you have meta-data security built-in. By default, a user can't even see the existence of an
object they don't have permissions to use. Database is the one exception though, but you can handle
that through the VIEW DEFINITION permission.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Joe Mills" <joemills84@.hotmail.com> wrote in message news:u2y1H$0BHHA.2328@.TK2MSFTNGP02.phx.gbl...
> Hi,
> I'm migrating a load of databases from a SQL 2000 server to SQL 2005 and was wondering if anyone
> knew how to restrict the list of databases that users see when they connect using the Management
> Studio to only those that they have access to? This was done in SQL 2000 by using the following:
> http://support.microsoft.com/default.aspx/kb/889696
> Any help is appreciated.
> Thanks - Joe.
>

Possible to restrict which dbs are shown in Management Studio...

Hi,
I'm migrating a load of databases from a SQL 2000 server to SQL 2005 and was
wondering if anyone knew how to restrict the list of databases that users
see when they connect using the Management Studio to only those that they
have access to? This was done in SQL 2000 by using the following:
http://support.microsoft.com/default.aspx/kb/889696
Any help is appreciated.
Thanks - Joe.In 2005, you have meta-data security built-in. By default, a user can't even
see the existence of an
object they don't have permissions to use. Database is the one exception tho
ugh, but you can handle
that through the VIEW DEFINITION permission.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Joe Mills" <joemills84@.hotmail.com> wrote in message news:u2y1H$0BHHA.2328@.TK2MSFTNGP02.phx
.gbl...
> Hi,
> I'm migrating a load of databases from a SQL 2000 server to SQL 2005 and w
as wondering if anyone
> knew how to restrict the list of databases that users see when they connec
t using the Management
> Studio to only those that they have access to? This was done in SQL 2000 b
y using the following:
> http://support.microsoft.com/default.aspx/kb/889696
> Any help is appreciated.
> Thanks - Joe.
>

Ports

When replicating between 2 sql 2000 databases, what port is used? Is it
1433?
Best regards
TrondSQL Server uses
port 1433 for TCP and port 1434 forUDP
best Regards,
Chandra
http://chanduas.blogspot.com/
---
"Trond" wrote:

> When replicating between 2 sql 2000 databases, what port is used? Is it
> 1433?
> Best regards
> Trond
>
>