Discussion :

[kayser]

Bonjour,

Je viens de migrer de SQL SERVER 2000 vers SQL SERVER 2008 R2.
Le nouvel environnement est bien différent à tel point que je n'arrive pas à faire une requête sur une table pour en modifier le contenu...
Savez vous comment faire ?

Il y a bien l'option "modifier les 200 lignes du haut"... mais dans ces 200 lignes y a pas forcément la ligne voulue... Donc je sais pas comment faire et si je dois utiliser un autre outil ??

Merci

[Philippe Robert]

Uniquement par l'instruction SQL d'update.

A mon avis, ce système a été mis en place pour protéger le DBA. En effet, en SQL 2000, lorsque tu lisais une table de cette manière, tout le contenu de la table était lu. Sur des petites tables, çà va, mais sur des tables volumineuse...

A+

[sevyc64]

La limite des 200 (1000 pour un SELECT) est propre à Management Studio et est modifiable dans les options

Menu Outils/Option, dérouler la branche "Explorateur d'objet SQL Server", rubrique Commandes, tu peux modifier cette limite, et si tu met 0, ça enlève la limite (toute la table sera retournée/modifiable)

[kayser]

Ah mince...
Et pour les requêtes, y a t il uniquement par script ? ou y a t il possibilité d'avoir une interface graphique ?

Merci

[mikedavem]

Personnellement je trouve cette option dangereuse. On ne devrait pas pouvoir modifier une ligne de données d'une table de cette façon car le DBA ne contrôle pas la manière dont l'opération est réalisée.

++

[kayser]

La limite des 200 (1000 pour un SELECT) est propre à Management Studio et est modifiable dans les options

Menu Outils/Option, dérouler la branche "Explorateur d'objet SQL Server", rubrique Commandes, tu peux modifier cette limite, et si tu met 0, ça enlève la limite (toute la table sera retournée/modifiable)

C'est bon à savoir merci.

Mais ca devient lourd à chercher s'il y a que quelques lignes à modifier... dommage qu'on puisse pas faire une requête pour en modifier le contenu...

[sevyc64]

Tu eux toujours faire une requete bien entendu

Code :

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

UPDATE TaTable SET TonChamp=TaValeur WHERE TaCondition

TaCondition étant la condition de tri servant à isoler le ou les enregistrements à modifier

Nota : C'est exactement ce que fait Management Studio en tache de fond lorsqu'on modifie un enregistrement dans la grille.

On ne devrait pas pouvoir modifier une ligne de données d'une table de cette façon car le DBA ne contrôle pas la manière dont l'opération est réalisée.

Que tu modifie par l'interface de SSMS ou par une requete, normalement, les contraintes doivent s'appliquer de la même manière puisque la modification est de toute façon faite par une requete UPDATE

[kayser]

ok merci pour vos infos.

[mikedavem]

Que tu modifie par l'interface de SSMS ou par une requete, normalement, les contraintes doivent s'appliquer de la même manière puisque la modification est de toute façon faite par une requete UPDATE

Effectivement mais une erreur peut être faite très rapidement via le designer .. Un clic de trop, une modification faite par mégarde ...

Le faire par requête permet d'éliminer ce genre de problèmes.

++

[sevyc64]

Effectivement mais une erreur peut être faite très rapidement via le designer .. Un clic de trop, une modification faite par mégarde ...

Le faire par requête permet d'éliminer ce genre de problèmes.

Tout à fait, mais les mêmes risques existent aussi par requete.
Un filtre mal écrit, pas testé avant de lancer la modification, une partie de requete qui reste sélectionnée (après un copier-collé par exemple) excluant justement le filtre, et c'est toute une table qui se trouve modifiée au lieu de quelques enregistrements

[pcdata]

Même si le sujet date un peu, je suis toujours surpris de voir ce genre de discussion sur la sécurité des MàJ dans une DB :

- que tu puisses modifier seulement les 200 1er enregistrements ou tous, ça change quoi ?!
La fonctionnalité est bridée par défaut certes mais elle est modifiable et si elle existe c'est qu'elle est utile.

Et dans un environnement professionnel de toute façon, tu fais d'abord ton script ou ta modif à la main sur ta base de données en local pour tester justement, puis sur ton serveur de pré-production pour vérifier à nouveau que ton script ou ta modif fonctionne, puis sur ton serveur de production.

Donc sauf à être débile et inconscient ou très tête en l'air, tu fais attention à ce que tu fais avec des précautions d'usages non !??

Mais faut croire que ces procédures de "précaution" ne sont pas mise en application chez tout le monde.
Professionnel ?!! Bizare, bizare...

[Philippe Robert]

Par expérience, si une possibilité d'erreur existe, elle a toute les chances de se produire, surtout l'erreur humaine.