Discussion :

[Ikebukuro]

Hello,

Petite question, quand j'exécute le code ci-dessous, le SELECT se fait dans la base TEST même si ma base par défaut est la base TEST_DEV

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
USE [TEST]
SELECT * FROM clients;

MAIS si, après cette première exécution, je sélectionne uniquement le SELECT et je fais F5 dans SSMS : le SELECT se fait encore dans la base TEST ou dans TEST_DEV?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM clients;

En clair, est-ce que le premier USE TEST a positionné dans ma session la base par défaut comme TEST ou bien ce n'est pas le cas?
Si ce n'est pas le cas, est-ce qu'une bonne pratique ne serait pas de TOUJOURS préfixer les objets par le nom de la base et du schéma pour éviter ce genre de pb? on fait ceinture et bretelle mais c'est plus sécure!

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
USE [TEST]
SELECT * FROM TEST.USER1.clients;

[SQLpro]

La notion de base par défaut n'existe pas en soi.

Vous êtes toujours dans le contexte d'une base de données.

La commande USE permet de changer le contexte d'exécution et donc de passer d'une base à l'autre dans les limites suivantes :

• un utilisateur associé à votre compte de connexion doit exister dans la base dans laquelle vous voulez exécuter vos commandes
• en l'absence d'utilisateur associé à votre compte de connexion et si l'utilisateur "guest" est actif et possède des privilèges, vous pourrez séjourner dans cette base
• dans tous les autres cas, vous ne pourrez pas changer le contexte.

C'est la seule commande et il n'y en a pas d'autre pour changer le contexte d'une base.

La commande use peut être lancée :

• littéralement en tapant USE <nom_base> dans l'éditeur de requête et en lançant cette ligne de code
• en utilisant la liste déroulante qui lance la commande USE à votre place.

ATTENTION : l'interface SSMS est trompeuse dans le sens ou chaque fenêtre d'édition des requêtes possède sa propre connexion, et il en est ainsi aussi de l'explorateur SQL...

En conclusion vous n'avez pas changé de contexte entre la requête 1 et la 2

En ce qui concerne la notation pointée avec le nom de la base, elle ne devrait être qu'exceptionnelle ! En effet en cas de changement du nom de la base (imposée par certains clients) ce serait la m...

Et surtout ne confondez pas base de données et schéma SQL, confusion dramatique que l'on constate assez systématiquement avec les gens venant du monde Oracle et de ses mauvaises pratiques en la matière !

A +

[Ikebukuro]

Donc, en résumé, quand je fais un
USE BASE B1;
dans une fenêtre query de SSMS, je n'ai pas à le refaire avant chaque opération T-SQL car la base de cette fenêtre query a été fixée à B1.

Euh, c'est quoi la confusion entre Schéma et base pour ceux qui viennent d'Oracle?

[SQLpro]

Donc, en résumé, quand je fais un
USE BASE B1;
dans une fenêtre query de SSMS, je n'ai pas à le refaire avant chaque opération T-SQL car la base de cette fenêtre query a été fixée à B1.

YEP !
N'oublie pas que chaque fenêtre est indépendantes :
1) les différentes fenêtre d'édition des requêtes ont chacune leur connexion et leur contexte.
2) l'explorateur d'objets à sa propre connexion et donc son propre contexte...
3) si tu utilise certains addin SSMS qui permettent d'enrichir le fonctionnement (SQL prompt, Apex SQL...) ces derniers ont leur propre connexion...

Euh, c'est quoi la confusion entre Schéma et base pour ceux qui viennent d'Oracle?

Dans Oracle, comme à l'origine il n'y avait qu'une seule base possible, beaucoup de développeurs jouaient sur les schéma SQL pour simuler différentes bases. Alors que SQL Server a toujours été multibase et multi schéma comme PostGreSQL par exemple. Ceci a changé avec le version 12 d'oracle (multitenant) mais comme c'est plus cher et que cela ne résous rien (un seul JT, même collation pour les bases...), personnes ne l'utilise, conservant les mauvaises habitudes Oracle.

A +