dbo

Serges Drennade

20/10/2006 à 14:54

Le Fri, 20 Oct 2006 14:13:26 +0200, Ch. a écrit :

tu changes le nom?

--
serges drennade
20/10/2006 14:54:10

Ch.

20/10/2006 à 16:08

je ne comprends pas ce que tu veux dire mais en gros c'est le proprio qui
apparait je ne peux l'enlever ?
mais par contre j'aimerais le faire disparaitre de l'affichage !

"Serges Drennade" a écrit dans le message de news:
y2etejmphg0s$

Patrice

20/10/2006 à 17:03

Comme cela pourrait introduire des ambiguïtés (il fait partie du nom de la
table) je ne pense pas que cela soit prévu...

--
Patrice

"Ch." a écrit dans le message de news:

Ch.

20/10/2006 à 18:42

bha c'est dommage car c'est asser genant et cela n'y ete pas en SQL 2000.

pas glop !

"Patrice" a écrit dans le message de news:
%

Fred BROUARD

22/10/2006 à 10:39

Bonjour,

Ch. a écrit :

Non dbo n'est pas le propriétaire comme on vous l'a indiqué de manière
erronée.

dbo est le SCHEMA par défaut dans toute base SQL Server.
Un schema appartient à un propriétaire. Ceci était confus avant la
version 2005.

Vous ne pouvez pas l'enlever, mais vous pouvez définir d'autres schémas.

La norme SQL prévoit qu'un CATALOG (ce que les éditeurs apelle une base
de données) est constituée de SCHEMAs (en fait des modules dans la base)
et c'est au niveau du schéma seulement que l'on peut créer les objets de
la base.

Ainsi un nom d'objet est toujours composé de 3 parties :
CATALOG.SCHEMA.OBJET.
Vous vous en rendrez compte en affichant les informations de schéma à
l'aide des vues :
INFORMATION_SCHEMA.TABLES
INFORMATION_SCHEMA.COLUMNS
INFORMATION_SCHEMA...

Votre intérêt est d'utiliser ces schémas ne serait-ce que pour prévoir
l'octroi de privilèges au niveau schéma.

De plus la création des objets au sein d'un schéma permet d'éviter les
problématiques de références arborescente, telle que l'obligation de
créer la table client avant la table commande...

Exemple :

USE master
GO

IF EXISTS (SELECT *
FROM master.INFORMATION_SCHEMA.SCHEMATA
WHERE CATALOG_NAME = 'DB_MICROSOFT')
DROP DATABASE DB_MICROSOFT
GO

CREATE DATABASE DB_MICROSOFT
GO

USE DB_MICROSOFT
GO

-- création de divers utilisateurs ...
sp_addlogin 'USR_SQL_MICROSOFT1', 'MICROSOFT', 'DB_MICROSOFT'
GO

sp_addlogin 'USR_SQL_MICROSOFT2', 'MICROSOFT', 'DB_MICROSOFT'
GO

-- ... et de leurs accès à la base DB_MICROSOFT
sp_grantdbaccess 'USR_SQL_MICROSOFT1'
GO

sp_grantdbaccess 'USR_SQL_MICROSOFT2'
GO

-- création d'un schema pour l'utilisateur USR_SQL_MICROSOFT1
CREATE SCHEMA AUTHORIZATION USR_SQL_MICROSOFT1

-- on octroi des privilèges sur des objets qui n'existe pas encore
GRANT SELECT
ON USR_SQL_MICROSOFT1.V_CLIENT_CLI
TO USR_SQL_MICROSOFT2

-- on créé une vue sur des objets qui n'existent pas encore
CREATE VIEW USR_SQL_MICROSOFT1.V_CLIENT_CLI
AS
SELECT *
FROM USR_SQL_MICROSOFT1.T_CLIENT_CLI

-- on créé une table faisant référence à des objets qui n'existent pas
-- encore
CREATE TABLE USR_SQL_MICROSOFT1.T_COMMANDE_CMD
(CMD_ID INT NOT NULL PRIMARY KEY,
CLI_ID INT NOT NULL
FOREIGN KEY
REFERENCES USR_SQL_MICROSOFT1.T_CLIENT_CLI (CLI_ID),
CMD_DATE DATETIME NOT NULL)

CREATE TABLE USR_SQL_MICROSOFT1.T_CLIENT_CLI
(CLI_ID INT NOT NULL PRIMARY KEY,
CLI_NOM CHAR(32) NOT NULL)
GO
-- fin de création du schéma

-- création d'une table de même nom pour le schéma USR_SQL_MICROSOFT2
CREATE TABLE USR_SQL_MICROSOFT2.T_CLIENT_CLI
(CLI_ID INT NOT NULL PRIMARY KEY,
CLI_NOM CHAR(32) NOT NULL)
GO

A +

PS : je ne saurait trop vous conseiller la lecture de mon site et mieux
encore l'un de mes bouquins pour ce qui est de comprendre ce genre de
concepts !

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************

Bonjour,

Ch. a écrit :

Non dbo n'est pas le propriétaire comme on vous l'a indiqué de manière
erronée.

dbo est le SCHEMA par défaut dans toute base SQL Server.
Un schema appartient à un propriétaire. Ceci était confus avant la
version 2005.

Vous ne pouvez pas l'enlever, mais vous pouvez définir d'autres schémas.

La norme SQL prévoit qu'un CATALOG (ce que les éditeurs apelle une base
de données) est constituée de SCHEMAs (en fait des modules dans la base)
et c'est au niveau du schéma seulement que l'on peut créer les objets de
la base.

Ainsi un nom d'objet est toujours composé de 3 parties :
CATALOG.SCHEMA.OBJET.
Vous vous en rendrez compte en affichant les informations de schéma à
l'aide des vues :
INFORMATION_SCHEMA.TABLES
INFORMATION_SCHEMA.COLUMNS
INFORMATION_SCHEMA...

Votre intérêt est d'utiliser ces schémas ne serait-ce que pour prévoir
l'octroi de privilèges au niveau schéma.

De plus la création des objets au sein d'un schéma permet d'éviter les
problématiques de références arborescente, telle que l'obligation de
créer la table client avant la table commande...

Exemple :

USE master
GO

IF EXISTS (SELECT *
FROM master.INFORMATION_SCHEMA.SCHEMATA
WHERE CATALOG_NAME = 'DB_MICROSOFT')
DROP DATABASE DB_MICROSOFT
GO

CREATE DATABASE DB_MICROSOFT
GO

USE DB_MICROSOFT
GO

-- création de divers utilisateurs ...
sp_addlogin 'USR_SQL_MICROSOFT1', 'MICROSOFT', 'DB_MICROSOFT'
GO

sp_addlogin 'USR_SQL_MICROSOFT2', 'MICROSOFT', 'DB_MICROSOFT'
GO

-- ... et de leurs accès à la base DB_MICROSOFT
sp_grantdbaccess 'USR_SQL_MICROSOFT1'
GO

sp_grantdbaccess 'USR_SQL_MICROSOFT2'
GO

-- création d'un schema pour l'utilisateur USR_SQL_MICROSOFT1
CREATE SCHEMA AUTHORIZATION USR_SQL_MICROSOFT1

-- on octroi des privilèges sur des objets qui n'existe pas encore
GRANT SELECT
ON USR_SQL_MICROSOFT1.V_CLIENT_CLI
TO USR_SQL_MICROSOFT2

-- on créé une vue sur des objets qui n'existent pas encore
CREATE VIEW USR_SQL_MICROSOFT1.V_CLIENT_CLI
AS
SELECT *
FROM USR_SQL_MICROSOFT1.T_CLIENT_CLI

-- on créé une table faisant référence à des objets qui n'existent pas
-- encore
CREATE TABLE USR_SQL_MICROSOFT1.T_COMMANDE_CMD
(CMD_ID INT NOT NULL PRIMARY KEY,
CLI_ID INT NOT NULL
FOREIGN KEY
REFERENCES USR_SQL_MICROSOFT1.T_CLIENT_CLI (CLI_ID),
CMD_DATE DATETIME NOT NULL)

CREATE TABLE USR_SQL_MICROSOFT1.T_CLIENT_CLI
(CLI_ID INT NOT NULL PRIMARY KEY,
CLI_NOM CHAR(32) NOT NULL)
GO
-- fin de création du schéma

-- création d'une table de même nom pour le schéma USR_SQL_MICROSOFT2
CREATE TABLE USR_SQL_MICROSOFT2.T_CLIENT_CLI
(CLI_ID INT NOT NULL PRIMARY KEY,
CLI_NOM CHAR(32) NOT NULL)
GO

A +

PS : je ne saurait trop vous conseiller la lecture de mon site et mieux
encore l'un de mes bouquins pour ce qui est de comprendre ce genre de
concepts !

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour,

Ch. a écrit :

Non dbo n'est pas le propriétaire comme on vous l'a indiqué de manière
erronée.

dbo est le SCHEMA par défaut dans toute base SQL Server.
Un schema appartient à un propriétaire. Ceci était confus avant la
version 2005.

Vous ne pouvez pas l'enlever, mais vous pouvez définir d'autres schémas.

La norme SQL prévoit qu'un CATALOG (ce que les éditeurs apelle une base
de données) est constituée de SCHEMAs (en fait des modules dans la base)
et c'est au niveau du schéma seulement que l'on peut créer les objets de
la base.

Ainsi un nom d'objet est toujours composé de 3 parties :
CATALOG.SCHEMA.OBJET.
Vous vous en rendrez compte en affichant les informations de schéma à
l'aide des vues :
INFORMATION_SCHEMA.TABLES
INFORMATION_SCHEMA.COLUMNS
INFORMATION_SCHEMA...

Votre intérêt est d'utiliser ces schémas ne serait-ce que pour prévoir
l'octroi de privilèges au niveau schéma.

De plus la création des objets au sein d'un schéma permet d'éviter les
problématiques de références arborescente, telle que l'obligation de
créer la table client avant la table commande...

Exemple :

USE master
GO

IF EXISTS (SELECT *
FROM master.INFORMATION_SCHEMA.SCHEMATA
WHERE CATALOG_NAME = 'DB_MICROSOFT')
DROP DATABASE DB_MICROSOFT
GO

CREATE DATABASE DB_MICROSOFT
GO

USE DB_MICROSOFT
GO

-- création de divers utilisateurs ...
sp_addlogin 'USR_SQL_MICROSOFT1', 'MICROSOFT', 'DB_MICROSOFT'
GO

sp_addlogin 'USR_SQL_MICROSOFT2', 'MICROSOFT', 'DB_MICROSOFT'
GO

-- ... et de leurs accès à la base DB_MICROSOFT
sp_grantdbaccess 'USR_SQL_MICROSOFT1'
GO

sp_grantdbaccess 'USR_SQL_MICROSOFT2'
GO

-- création d'un schema pour l'utilisateur USR_SQL_MICROSOFT1
CREATE SCHEMA AUTHORIZATION USR_SQL_MICROSOFT1

-- on octroi des privilèges sur des objets qui n'existe pas encore
GRANT SELECT
ON USR_SQL_MICROSOFT1.V_CLIENT_CLI
TO USR_SQL_MICROSOFT2

-- on créé une vue sur des objets qui n'existent pas encore
CREATE VIEW USR_SQL_MICROSOFT1.V_CLIENT_CLI
AS
SELECT *
FROM USR_SQL_MICROSOFT1.T_CLIENT_CLI

-- on créé une table faisant référence à des objets qui n'existent pas
-- encore
CREATE TABLE USR_SQL_MICROSOFT1.T_COMMANDE_CMD
(CMD_ID INT NOT NULL PRIMARY KEY,
CLI_ID INT NOT NULL
FOREIGN KEY
REFERENCES USR_SQL_MICROSOFT1.T_CLIENT_CLI (CLI_ID),
CMD_DATE DATETIME NOT NULL)

CREATE TABLE USR_SQL_MICROSOFT1.T_CLIENT_CLI
(CLI_ID INT NOT NULL PRIMARY KEY,
CLI_NOM CHAR(32) NOT NULL)
GO
-- fin de création du schéma

-- création d'une table de même nom pour le schéma USR_SQL_MICROSOFT2
CREATE TABLE USR_SQL_MICROSOFT2.T_CLIENT_CLI
(CLI_ID INT NOT NULL PRIMARY KEY,
CLI_NOM CHAR(32) NOT NULL)
GO

A +

PS : je ne saurait trop vous conseiller la lecture de mon site et mieux
encore l'un de mes bouquins pour ce qui est de comprendre ce genre de
concepts !

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************

SQLpro

22/10/2006 à 13:48

Bonjour,

Ch. a écrit :

Non dbo n'est pas le propriétaire comme on vous l'a indiqué de
manière erronée.

dbo est le SCHEMA par défaut dans toute base SQL Server.
Un schema appartient à un propriétaire. Ceci était confus avant la
version 2005.

Vous ne pouvez pas l'enlever, mais vous pouvez définir d'autres
schémas.

La norme SQL prévoit qu'un CATALOG (ce que les éditeurs apelle une
base de données) est constituée de SCHEMAs (en fait des modules dans
la base) et c'est au niveau du schéma seulement que l'on peut créer
les objets de la base.

Ainsi un nom d'objet est toujours composé de 3 parties :
CATALOG.SCHEMA.OBJET.
Vous vous en rendrez compte en affichant les informations de schéma à
l'aide des vues :
INFORMATION_SCHEMA.TABLES
INFORMATION_SCHEMA.COLUMNS
INFORMATION_SCHEMA...

Votre intérêt est d'utiliser ces schémas ne serait-ce que pour
prévoir l'octroi de privilèges au niveau schéma.

De plus la création des objets au sein d'un schéma permet d'éviter
les problématiques de références arborescente, telle que
l'obligation de créer la table client avant la table commande...

Exemple :

USE master
GO

IF EXISTS (SELECT *
FROM master.INFORMATION_SCHEMA.SCHEMATA
WHERE CATALOG_NAME = 'DB_MICROSOFT')
DROP DATABASE DB_MICROSOFT
GO

CREATE DATABASE DB_MICROSOFT
GO

USE DB_MICROSOFT
GO

-- création de divers utilisateurs ...
sp_addlogin 'USR_SQL_MICROSOFT1', 'MICROSOFT', 'DB_MICROSOFT'
GO

sp_addlogin 'USR_SQL_MICROSOFT2', 'MICROSOFT', 'DB_MICROSOFT'
GO

-- ... et de leurs accès à la base DB_MICROSOFT
sp_grantdbaccess 'USR_SQL_MICROSOFT1'
GO

sp_grantdbaccess 'USR_SQL_MICROSOFT2'
GO

-- création d'un schema pour l'utilisateur USR_SQL_MICROSOFT1
CREATE SCHEMA AUTHORIZATION USR_SQL_MICROSOFT1

-- on octroi des privilèges sur des objets qui n'existe pas encore
GRANT SELECT
ON USR_SQL_MICROSOFT1.V_CLIENT_CLI
TO USR_SQL_MICROSOFT2

-- on créé une vue sur des objets qui n'existent pas encore
CREATE VIEW USR_SQL_MICROSOFT1.V_CLIENT_CLI
AS
SELECT *
FROM USR_SQL_MICROSOFT1.T_CLIENT_CLI

-- on créé une table faisant référence à des objets qui n'existent
pas
-- encore
CREATE TABLE USR_SQL_MICROSOFT1.T_COMMANDE_CMD
(CMD_ID INT NOT NULL PRIMARY KEY,
CLI_ID INT NOT NULL
FOREIGN KEY
REFERENCES USR_SQL_MICROSOFT1.T_CLIENT_CLI (CLI_ID),
CMD_DATE DATETIME NOT NULL)

CREATE TABLE USR_SQL_MICROSOFT1.T_CLIENT_CLI
(CLI_ID INT NOT NULL PRIMARY KEY,
CLI_NOM CHAR(32) NOT NULL)
GO
-- fin de création du schéma

-- création d'une table de même nom pour le schéma
USR_SQL_MICROSOFT2
CREATE TABLE USR_SQL_MICROSOFT2.T_CLIENT_CLI
(CLI_ID INT NOT NULL PRIMARY KEY,
CLI_NOM CHAR(32) NOT NULL)
GO

A +

PS : je ne saurait trop vous conseiller la lecture de mon site et mieux
encore l'un de mes bouquins pour ce qui est de comprendre ce genre de
concepts !

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage
SQL
Le site sur le langage SQL et les SGBDR :
http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning,
optimisation
********************* http://www.datasapiens.com ***********************

Bonjour,

Ch. a écrit :

Non dbo n'est pas le propriétaire comme on vous l'a indiqué de
manière erronée.

dbo est le SCHEMA par défaut dans toute base SQL Server.
Un schema appartient à un propriétaire. Ceci était confus avant la
version 2005.

Vous ne pouvez pas l'enlever, mais vous pouvez définir d'autres
schémas.

La norme SQL prévoit qu'un CATALOG (ce que les éditeurs apelle une
base de données) est constituée de SCHEMAs (en fait des modules dans
la base) et c'est au niveau du schéma seulement que l'on peut créer
les objets de la base.

Ainsi un nom d'objet est toujours composé de 3 parties :
CATALOG.SCHEMA.OBJET.
Vous vous en rendrez compte en affichant les informations de schéma à
l'aide des vues :
INFORMATION_SCHEMA.TABLES
INFORMATION_SCHEMA.COLUMNS
INFORMATION_SCHEMA...

Votre intérêt est d'utiliser ces schémas ne serait-ce que pour
prévoir l'octroi de privilèges au niveau schéma.

De plus la création des objets au sein d'un schéma permet d'éviter
les problématiques de références arborescente, telle que
l'obligation de créer la table client avant la table commande...

Exemple :

USE master
GO

IF EXISTS (SELECT *
FROM master.INFORMATION_SCHEMA.SCHEMATA
WHERE CATALOG_NAME = 'DB_MICROSOFT')
DROP DATABASE DB_MICROSOFT
GO

CREATE DATABASE DB_MICROSOFT
GO

USE DB_MICROSOFT
GO

-- création de divers utilisateurs ...
sp_addlogin 'USR_SQL_MICROSOFT1', 'MICROSOFT', 'DB_MICROSOFT'
GO

sp_addlogin 'USR_SQL_MICROSOFT2', 'MICROSOFT', 'DB_MICROSOFT'
GO

-- ... et de leurs accès à la base DB_MICROSOFT
sp_grantdbaccess 'USR_SQL_MICROSOFT1'
GO

sp_grantdbaccess 'USR_SQL_MICROSOFT2'
GO

-- création d'un schema pour l'utilisateur USR_SQL_MICROSOFT1
CREATE SCHEMA AUTHORIZATION USR_SQL_MICROSOFT1

-- on octroi des privilèges sur des objets qui n'existe pas encore
GRANT SELECT
ON USR_SQL_MICROSOFT1.V_CLIENT_CLI
TO USR_SQL_MICROSOFT2

-- on créé une vue sur des objets qui n'existent pas encore
CREATE VIEW USR_SQL_MICROSOFT1.V_CLIENT_CLI
AS
SELECT *
FROM USR_SQL_MICROSOFT1.T_CLIENT_CLI

-- on créé une table faisant référence à des objets qui n'existent
pas
-- encore
CREATE TABLE USR_SQL_MICROSOFT1.T_COMMANDE_CMD
(CMD_ID INT NOT NULL PRIMARY KEY,
CLI_ID INT NOT NULL
FOREIGN KEY
REFERENCES USR_SQL_MICROSOFT1.T_CLIENT_CLI (CLI_ID),
CMD_DATE DATETIME NOT NULL)

CREATE TABLE USR_SQL_MICROSOFT1.T_CLIENT_CLI
(CLI_ID INT NOT NULL PRIMARY KEY,
CLI_NOM CHAR(32) NOT NULL)
GO
-- fin de création du schéma

-- création d'une table de même nom pour le schéma
USR_SQL_MICROSOFT2
CREATE TABLE USR_SQL_MICROSOFT2.T_CLIENT_CLI
(CLI_ID INT NOT NULL PRIMARY KEY,
CLI_NOM CHAR(32) NOT NULL)
GO

A +

PS : je ne saurait trop vous conseiller la lecture de mon site et mieux
encore l'un de mes bouquins pour ce qui est de comprendre ce genre de
concepts !

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage
SQL
Le site sur le langage SQL et les SGBDR :
http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning,
optimisation
********************* http://www.datasapiens.com ***********************

Vous avez filtré cet utilisateur ! Consultez son message

Bonjour,

Ch. a écrit :

Non dbo n'est pas le propriétaire comme on vous l'a indiqué de
manière erronée.

dbo est le SCHEMA par défaut dans toute base SQL Server.
Un schema appartient à un propriétaire. Ceci était confus avant la
version 2005.

Vous ne pouvez pas l'enlever, mais vous pouvez définir d'autres
schémas.

La norme SQL prévoit qu'un CATALOG (ce que les éditeurs apelle une
base de données) est constituée de SCHEMAs (en fait des modules dans
la base) et c'est au niveau du schéma seulement que l'on peut créer
les objets de la base.

Ainsi un nom d'objet est toujours composé de 3 parties :
CATALOG.SCHEMA.OBJET.
Vous vous en rendrez compte en affichant les informations de schéma à
l'aide des vues :
INFORMATION_SCHEMA.TABLES
INFORMATION_SCHEMA.COLUMNS
INFORMATION_SCHEMA...

Votre intérêt est d'utiliser ces schémas ne serait-ce que pour
prévoir l'octroi de privilèges au niveau schéma.

De plus la création des objets au sein d'un schéma permet d'éviter
les problématiques de références arborescente, telle que
l'obligation de créer la table client avant la table commande...

Exemple :

USE master
GO

IF EXISTS (SELECT *
FROM master.INFORMATION_SCHEMA.SCHEMATA
WHERE CATALOG_NAME = 'DB_MICROSOFT')
DROP DATABASE DB_MICROSOFT
GO

CREATE DATABASE DB_MICROSOFT
GO

USE DB_MICROSOFT
GO

-- création de divers utilisateurs ...
sp_addlogin 'USR_SQL_MICROSOFT1', 'MICROSOFT', 'DB_MICROSOFT'
GO

sp_addlogin 'USR_SQL_MICROSOFT2', 'MICROSOFT', 'DB_MICROSOFT'
GO

-- ... et de leurs accès à la base DB_MICROSOFT
sp_grantdbaccess 'USR_SQL_MICROSOFT1'
GO

sp_grantdbaccess 'USR_SQL_MICROSOFT2'
GO

-- création d'un schema pour l'utilisateur USR_SQL_MICROSOFT1
CREATE SCHEMA AUTHORIZATION USR_SQL_MICROSOFT1

-- on octroi des privilèges sur des objets qui n'existe pas encore
GRANT SELECT
ON USR_SQL_MICROSOFT1.V_CLIENT_CLI
TO USR_SQL_MICROSOFT2

-- on créé une vue sur des objets qui n'existent pas encore
CREATE VIEW USR_SQL_MICROSOFT1.V_CLIENT_CLI
AS
SELECT *
FROM USR_SQL_MICROSOFT1.T_CLIENT_CLI

-- on créé une table faisant référence à des objets qui n'existent
pas
-- encore
CREATE TABLE USR_SQL_MICROSOFT1.T_COMMANDE_CMD
(CMD_ID INT NOT NULL PRIMARY KEY,
CLI_ID INT NOT NULL
FOREIGN KEY
REFERENCES USR_SQL_MICROSOFT1.T_CLIENT_CLI (CLI_ID),
CMD_DATE DATETIME NOT NULL)

CREATE TABLE USR_SQL_MICROSOFT1.T_CLIENT_CLI
(CLI_ID INT NOT NULL PRIMARY KEY,
CLI_NOM CHAR(32) NOT NULL)
GO
-- fin de création du schéma

-- création d'une table de même nom pour le schéma
USR_SQL_MICROSOFT2
CREATE TABLE USR_SQL_MICROSOFT2.T_CLIENT_CLI
(CLI_ID INT NOT NULL PRIMARY KEY,
CLI_NOM CHAR(32) NOT NULL)
GO

A +

PS : je ne saurait trop vous conseiller la lecture de mon site et mieux
encore l'un de mes bouquins pour ce qui est de comprendre ce genre de
concepts !

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage
SQL
Le site sur le langage SQL et les SGBDR :
http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning,
optimisation
********************* http://www.datasapiens.com ***********************

Ch.

31/10/2006 à 20:38

justement est-ce que ces concept de schema sont expliqué quelques part ?
bouquins ou site ?
ton dernier bouquin en parle t'il ?

Ch.

ps: au fait l'idée de depart c'est juste de masquer dbo.nomdelatable dans le
management studio loin de moi l'idée de le virer ;)
toutefois j'ai pleins de concept à piger et j'ai en plus plein de taf alors
j'ai du mal a tout faire heureusement que vous etes tous la pour me filer un
coup de main !

"Fred BROUARD" a écrit dans le message de news:
e$

justement est-ce que ces concept de schema sont expliqué quelques part ?
bouquins ou site ?
ton dernier bouquin en parle t'il ?

Ch.

ps: au fait l'idée de depart c'est juste de masquer dbo.nomdelatable dans le
management studio loin de moi l'idée de le virer ;)
toutefois j'ai pleins de concept à piger et j'ai en plus plein de taf alors
j'ai du mal a tout faire heureusement que vous etes tous la pour me filer un
coup de main !

"Fred BROUARD" <brouardf@club-internet.fr> a écrit dans le message de news:
e$WT2Zb9GHA.3396@TK2MSFTNGP04.phx.gbl...

Vous avez filtré cet utilisateur ! Consultez son message

justement est-ce que ces concept de schema sont expliqué quelques part ?
bouquins ou site ?
ton dernier bouquin en parle t'il ?

Ch.

ps: au fait l'idée de depart c'est juste de masquer dbo.nomdelatable dans le
management studio loin de moi l'idée de le virer ;)
toutefois j'ai pleins de concept à piger et j'ai en plus plein de taf alors
j'ai du mal a tout faire heureusement que vous etes tous la pour me filer un
coup de main !

"Fred BROUARD" a écrit dans le message de news:
e$

dbo

7 réponses

Veuillez sélectionner un problème