Is the default Owner for an Object always 'dbo' ?

In SQL Server 2005, when creating a TABLE, FUNCTION or PROCEDURE, what
governs who is the owner of the object.
Currently, from personal observation, it seems to be always 'dbo',
regardless of the schema that the object is being created in, or who is doing
the creating. Is this true, or are there other factors at play?
With the new seperation of user and schema, is there any advantage to having
objects within a schema owned by different people?
"Al" <Al@.discussions.microsoft.com> wrote in message
news:B6C51168-2ACF-4A70-B324-487C8E6E938C@.microsoft.com...
> In SQL Server 2005, when creating a TABLE, FUNCTION or PROCEDURE, what
> governs who is the owner of the object.
> Currently, from personal observation, it seems to be always 'dbo',
> regardless of the schema that the object is being created in, or who is
> doing
> the creating. Is this true, or are there other factors at play?
>
The default owner of an object is the owner of the schema. Not the user per
se, but "SCHEMA OWNER". If you change the owner of the schema all objects
in that schema owned by SCHEMA OWNER will have their ownership transferred.

> With the new seperation of user and schema, is there any advantage to
> having
> objects within a schema owned by different people?
No. I can't think of a scenario where this would be useful. If you want to
have objects owned by other users, give the user a new schema and make them
the owner of the schema.
David
|||No, the owner of objects is not always dbo by default... I think it
depends on the permission of the user who is creating the object. If
you are a logged in as a "sysadmin" user, then by default all objects
are owned by dbo. I've had a situation here where some developers were
creating objects and the objects were owned by them, not dbo - I'm not
sure what their permissions where however - good question which I will
investiage.
However, you can can have your developers do this, for example, to
ensure ownership is always dbo:
CREATE TABLE dbo.tablename
Al wrote:
> In SQL Server 2005, when creating a TABLE, FUNCTION or PROCEDURE, what
> governs who is the owner of the object.
> Currently, from personal observation, it seems to be always 'dbo',
> regardless of the schema that the object is being created in, or who is doing
> the creating. Is this true, or are there other factors at play?
> With the new seperation of user and schema, is there any advantage to having
> objects within a schema owned by different people?
|||<tootsuite@.gmail.com> wrote in message
news:1161621399.913644.324130@.m73g2000cwd.googlegr oups.com...
> No, the owner of objects is not always dbo by default... I think it
> depends on the permission of the user who is creating the object. If
> you are a logged in as a "sysadmin" user, then by default all objects
> are owned by dbo. I've had a situation here where some developers were
> creating objects and the objects were owned by them, not dbo - I'm not
> sure what their permissions where however - good question which I will
> investiage.
> However, you can can have your developers do this, for example, to
> ensure ownership is always dbo:
> CREATE TABLE dbo.tablename
>
This applies only to SQL 2000. Not 2005. Read up on user/schema
seperation.
David

Is the default Owner for an Object always 'dbo' ?

In SQL Server 2005, when creating a TABLE, FUNCTION or PROCEDURE, what
governs who is the owner of the object.
Currently, from personal observation, it seems to be always 'dbo',
regardless of the schema that the object is being created in, or who is doin
g
the creating. Is this true, or are there other factors at play?
With the new seperation of user and schema, is there any advantage to having
objects within a schema owned by different people?"Al" <Al@.discussions.microsoft.com> wrote in message
news:B6C51168-2ACF-4A70-B324-487C8E6E938C@.microsoft.com...
> In SQL Server 2005, when creating a TABLE, FUNCTION or PROCEDURE, what
> governs who is the owner of the object.
> Currently, from personal observation, it seems to be always 'dbo',
> regardless of the schema that the object is being created in, or who is
> doing
> the creating. Is this true, or are there other factors at play?
>
The default owner of an object is the owner of the schema. Not the user per
se, but "SCHEMA OWNER". If you change the owner of the schema all objects
in that schema owned by SCHEMA OWNER will have their ownership transferred.

> With the new seperation of user and schema, is there any advantage to
> having
> objects within a schema owned by different people?
No. I can't think of a scenario where this would be useful. If you want to
have objects owned by other users, give the user a new schema and make them
the owner of the schema.
David|||No, the owner of objects is not always dbo by default... I think it
depends on the permission of the user who is creating the object. If
you are a logged in as a "sysadmin" user, then by default all objects
are owned by dbo. I've had a situation here where some developers were
creating objects and the objects were owned by them, not dbo - I'm not
sure what their permissions where however - good question which I will
investiage.
However, you can can have your developers do this, for example, to
ensure ownership is always dbo:
CREATE TABLE dbo.tablename
Al wrote:
> In SQL Server 2005, when creating a TABLE, FUNCTION or PROCEDURE, what
> governs who is the owner of the object.
> Currently, from personal observation, it seems to be always 'dbo',
> regardless of the schema that the object is being created in, or who is do
ing
> the creating. Is this true, or are there other factors at play?
> With the new seperation of user and schema, is there any advantage to havi
ng
> objects within a schema owned by different people?|||<tootsuite@.gmail.com> wrote in message
news:1161621399.913644.324130@.m73g2000cwd.googlegroups.com...
> No, the owner of objects is not always dbo by default... I think it
> depends on the permission of the user who is creating the object. If
> you are a logged in as a "sysadmin" user, then by default all objects
> are owned by dbo. I've had a situation here where some developers were
> creating objects and the objects were owned by them, not dbo - I'm not
> sure what their permissions where however - good question which I will
> investiage.
> However, you can can have your developers do this, for example, to
> ensure ownership is always dbo:
> CREATE TABLE dbo.tablename
>
This applies only to SQL 2000. Not 2005. Read up on user/schema
seperation.
David

Is the default Owner for an Object always 'dbo' ?

In SQL Server 2005, when creating a TABLE, FUNCTION or PROCEDURE, what
governs who is the owner of the object.
Currently, from personal observation, it seems to be always 'dbo',
regardless of the schema that the object is being created in, or who is doing
the creating. Is this true, or are there other factors at play?
With the new seperation of user and schema, is there any advantage to having
objects within a schema owned by different people?"Al" <Al@.discussions.microsoft.com> wrote in message
news:B6C51168-2ACF-4A70-B324-487C8E6E938C@.microsoft.com...
> In SQL Server 2005, when creating a TABLE, FUNCTION or PROCEDURE, what
> governs who is the owner of the object.
> Currently, from personal observation, it seems to be always 'dbo',
> regardless of the schema that the object is being created in, or who is
> doing
> the creating. Is this true, or are there other factors at play?
>
The default owner of an object is the owner of the schema. Not the user per
se, but "SCHEMA OWNER". If you change the owner of the schema all objects
in that schema owned by SCHEMA OWNER will have their ownership transferred.
> With the new seperation of user and schema, is there any advantage to
> having
> objects within a schema owned by different people?
No. I can't think of a scenario where this would be useful. If you want to
have objects owned by other users, give the user a new schema and make them
the owner of the schema.
David|||No, the owner of objects is not always dbo by default... I think it
depends on the permission of the user who is creating the object. If
you are a logged in as a "sysadmin" user, then by default all objects
are owned by dbo. I've had a situation here where some developers were
creating objects and the objects were owned by them, not dbo - I'm not
sure what their permissions where however - good question which I will
investiage.
However, you can can have your developers do this, for example, to
ensure ownership is always dbo:
CREATE TABLE dbo.tablename
Al wrote:
> In SQL Server 2005, when creating a TABLE, FUNCTION or PROCEDURE, what
> governs who is the owner of the object.
> Currently, from personal observation, it seems to be always 'dbo',
> regardless of the schema that the object is being created in, or who is doing
> the creating. Is this true, or are there other factors at play?
> With the new seperation of user and schema, is there any advantage to having
> objects within a schema owned by different people?|||<tootsuite@.gmail.com> wrote in message
news:1161621399.913644.324130@.m73g2000cwd.googlegroups.com...
> No, the owner of objects is not always dbo by default... I think it
> depends on the permission of the user who is creating the object. If
> you are a logged in as a "sysadmin" user, then by default all objects
> are owned by dbo. I've had a situation here where some developers were
> creating objects and the objects were owned by them, not dbo - I'm not
> sure what their permissions where however - good question which I will
> investiage.
> However, you can can have your developers do this, for example, to
> ensure ownership is always dbo:
> CREATE TABLE dbo.tablename
>
This applies only to SQL 2000. Not 2005. Read up on user/schema
seperation.
Davidsql

Is Sql-Server 2005 Object Oriented DBMS

Greetings,
I would like to konw if Sqlserver 2005 supports Geographic Information
System (GIS) data, i.e., supports spatial data, like Oracle?
MTIA,
Grawshagrawsha2000@.yahoo.com wrote:
> Greetings,
> I would like to konw if Sqlserver 2005 supports Geographic Information
> System (GIS) data, i.e., supports spatial data, like Oracle?
>
> MTIA,
> Grawsha
SQL Server doesn't have specific features designed for GIS but it does
support user-defined datatypes and CLR (.NET) code in the database. You
can build "complex" types (points and vectors maybe) from .NET classes.
That may cover some of the features you have in mind.
As for OODBMS, it would help if you could be more specific. "OODBMS" is
commonly used as a marketing category or an imprecise term for any of
various different features and techniques. If you are looking for
encapsulation, inheritence and subclassing then you can achieve that
through .NET code either inside or outside the database server. If you
need an object store then you can also serialize .NET objects to a SQL
Server database.
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
--|||>> I would like to konw if Sqlserver 2005 supports Geographic Information
Searching MSDN bought up the following, not sure if helps:
http://msdn.microsoft.com/library/e...lValFuncSQL.asp
Anith

Is my object variable empty?

Hallo!

I got an object variable. I used it in a “Recordset destination”.

How can I proof if it is empty?

Isnull(@.[Benutzer::MyVar]) does not work!

One thing you can do is to shred through it and pop up a message with each value.

http://www.sqlis.com/59.aspx

|||

I decided to use a count (Countrow) while populating my recordset. Then I can have access to the variable just like @.[Benutzer::Count] > 0 ? true : false

|||Good idea.|||Remember to mark a post as answered, even if you are the one who answered it...