Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de
resultats issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il
me dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
comment faire pour avoir du code commun à plusieurs SP ?
Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de
resultats issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il
me dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
comment faire pour avoir du code commun à plusieurs SP ?
Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de
resultats issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il
me dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
comment faire pour avoir du code commun à plusieurs SP ?
Ch. a écrit :Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
évitez les tables temporaires et brecourrez à des tables fixe dans votre
base en ajoutant une colonne discriminant par utilisateur, par exemple au
moyen du SPID.
A +
comment faire pour avoir du code commun à plusieurs SP ?
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Ch. a écrit :
Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
évitez les tables temporaires et brecourrez à des tables fixe dans votre
base en ajoutant une colonne discriminant par utilisateur, par exemple au
moyen du SPID.
A +
comment faire pour avoir du code commun à plusieurs SP ?
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Ch. a écrit :Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
évitez les tables temporaires et brecourrez à des tables fixe dans votre
base en ajoutant une colonne discriminant par utilisateur, par exemple au
moyen du SPID.
A +
comment faire pour avoir du code commun à plusieurs SP ?
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Ch. a écrit :Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
évitez les tables temporaires et brecourrez à des tables fixe dans votre
base en ajoutant une colonne discriminant par utilisateur, par exemple au
moyen du SPID.
A +
comment faire pour avoir du code commun à plusieurs SP ?
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Ch. a écrit :
Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
évitez les tables temporaires et brecourrez à des tables fixe dans votre
base en ajoutant une colonne discriminant par utilisateur, par exemple au
moyen du SPID.
A +
comment faire pour avoir du code commun à plusieurs SP ?
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Ch. a écrit :Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
évitez les tables temporaires et brecourrez à des tables fixe dans votre
base en ajoutant une colonne discriminant par utilisateur, par exemple au
moyen du SPID.
A +
comment faire pour avoir du code commun à plusieurs SP ?
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Ch. a écrit :Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
évitez les tables temporaires et brecourrez à des tables fixe dans votre
base en ajoutant une colonne discriminant par utilisateur, par exemple au
moyen du SPID.
A +
comment faire pour avoir du code commun à plusieurs SP ?
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Ch. a écrit :
Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
évitez les tables temporaires et brecourrez à des tables fixe dans votre
base en ajoutant une colonne discriminant par utilisateur, par exemple au
moyen du SPID.
A +
comment faire pour avoir du code commun à plusieurs SP ?
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Ch. a écrit :Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
évitez les tables temporaires et brecourrez à des tables fixe dans votre
base en ajoutant une colonne discriminant par utilisateur, par exemple au
moyen du SPID.
A +
comment faire pour avoir du code commun à plusieurs SP ?
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Fred j'ai une question
j'ai testé cette methode qui me plait plus que beaucoup.
Mais comment eviter des blocages ou des locks quand l'appli est fortement
sollicter, et avec des volumes qui peuvent etre consequent ???
faut'il adopter preciser un type de verrou particulier lors de l'insert ?
comment peux t'on accélérer le delete ?
Merci par avance.
"Fred BROUARD" a écrit dans le message de
groupe
de discussion : #Ch. a écrit :Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de
resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas
il me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
évitez les tables temporaires et brecourrez à des tables fixe dans votre
base en ajoutant une colonne discriminant par utilisateur, par exemple au
moyen du SPID.
A +
comment faire pour avoir du code commun à plusieurs SP ?
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Fred j'ai une question
j'ai testé cette methode qui me plait plus que beaucoup.
Mais comment eviter des blocages ou des locks quand l'appli est fortement
sollicter, et avec des volumes qui peuvent etre consequent ???
faut'il adopter preciser un type de verrou particulier lors de l'insert ?
comment peux t'on accélérer le delete ?
Merci par avance.
"Fred BROUARD" <brouardf@club-internet.fr> a écrit dans le message de
groupe
de discussion : #zLYYOKlKHA.6096@TK2MSFTNGP02.phx.gbl...
Ch. a écrit :
Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de
resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas
il me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
évitez les tables temporaires et brecourrez à des tables fixe dans votre
base en ajoutant une colonne discriminant par utilisateur, par exemple au
moyen du SPID.
A +
comment faire pour avoir du code commun à plusieurs SP ?
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Fred j'ai une question
j'ai testé cette methode qui me plait plus que beaucoup.
Mais comment eviter des blocages ou des locks quand l'appli est fortement
sollicter, et avec des volumes qui peuvent etre consequent ???
faut'il adopter preciser un type de verrou particulier lors de l'insert ?
comment peux t'on accélérer le delete ?
Merci par avance.
"Fred BROUARD" a écrit dans le message de
groupe
de discussion : #Ch. a écrit :Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de
resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas
il me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
évitez les tables temporaires et brecourrez à des tables fixe dans votre
base en ajoutant une colonne discriminant par utilisateur, par exemple au
moyen du SPID.
A +
comment faire pour avoir du code commun à plusieurs SP ?
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Ch. a écrit :Fred j'ai une question
j'ai testé cette methode qui me plait plus que beaucoup.
Mais comment eviter des blocages ou des locks quand l'appli est fortement
sollicter, et avec des volumes qui peuvent etre consequent ???
en principe il ne devrait pas y avoir de blocage car chaque utilisateur
travaille sur un jeu de ligne différent. Néanmoins on peut forcer le
verrouillage de ligne en recréant l'index avec DISALLOW_PAGELOCK /
ALLOW_ROWLOCK (attention, si nombreuses lignes impactées => nombreux
verrous ce qui encombre la mémoire) et même faire des lectures sale en
repositionnant le niveau d'isolation à READ UNCOMMITTED
faut'il adopter preciser un type de verrou particulier lors de l'insert ?
comment peux t'on accélérer le delete ?
C'est une connerie que d'utiliser directement des tags de verrouillage
dans une requête :
1) il faut récrire la requête si l'on veut changer le comportement
2) cela empêche les mécanismes d'escalade de verrous qui améliore les
performances
Dans le principe tout code SQL devrait être séparé en 2 choses bien
distinctes :
d'un côté le code fonctionnel (INSERT, SELECT, UPDATE, DELETE)
de l'autre le code administratif ou technique : transaction, verrous,
index....
A +
Merci par avance.
"Fred BROUARD" a écrit dans le message de
groupe
de discussion : #Ch. a écrit :Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de
resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il
me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche
le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
évitez les tables temporaires et brecourrez à des tables fixe dans votre
base en ajoutant une colonne discriminant par utilisateur, par exemple
au
moyen du SPID.
A +
comment faire pour avoir du code commun à plusieurs SP ?
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Ch. a écrit :
Fred j'ai une question
j'ai testé cette methode qui me plait plus que beaucoup.
Mais comment eviter des blocages ou des locks quand l'appli est fortement
sollicter, et avec des volumes qui peuvent etre consequent ???
en principe il ne devrait pas y avoir de blocage car chaque utilisateur
travaille sur un jeu de ligne différent. Néanmoins on peut forcer le
verrouillage de ligne en recréant l'index avec DISALLOW_PAGELOCK /
ALLOW_ROWLOCK (attention, si nombreuses lignes impactées => nombreux
verrous ce qui encombre la mémoire) et même faire des lectures sale en
repositionnant le niveau d'isolation à READ UNCOMMITTED
faut'il adopter preciser un type de verrou particulier lors de l'insert ?
comment peux t'on accélérer le delete ?
C'est une connerie que d'utiliser directement des tags de verrouillage
dans une requête :
1) il faut récrire la requête si l'on veut changer le comportement
2) cela empêche les mécanismes d'escalade de verrous qui améliore les
performances
Dans le principe tout code SQL devrait être séparé en 2 choses bien
distinctes :
d'un côté le code fonctionnel (INSERT, SELECT, UPDATE, DELETE)
de l'autre le code administratif ou technique : transaction, verrous,
index....
A +
Merci par avance.
"Fred BROUARD" <brouardf@club-internet.fr> a écrit dans le message de
groupe
de discussion : #zLYYOKlKHA.6096@TK2MSFTNGP02.phx.gbl...
Ch. a écrit :
Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de
resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il
me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche
le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
évitez les tables temporaires et brecourrez à des tables fixe dans votre
base en ajoutant une colonne discriminant par utilisateur, par exemple
au
moyen du SPID.
A +
comment faire pour avoir du code commun à plusieurs SP ?
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Ch. a écrit :Fred j'ai une question
j'ai testé cette methode qui me plait plus que beaucoup.
Mais comment eviter des blocages ou des locks quand l'appli est fortement
sollicter, et avec des volumes qui peuvent etre consequent ???
en principe il ne devrait pas y avoir de blocage car chaque utilisateur
travaille sur un jeu de ligne différent. Néanmoins on peut forcer le
verrouillage de ligne en recréant l'index avec DISALLOW_PAGELOCK /
ALLOW_ROWLOCK (attention, si nombreuses lignes impactées => nombreux
verrous ce qui encombre la mémoire) et même faire des lectures sale en
repositionnant le niveau d'isolation à READ UNCOMMITTED
faut'il adopter preciser un type de verrou particulier lors de l'insert ?
comment peux t'on accélérer le delete ?
C'est une connerie que d'utiliser directement des tags de verrouillage
dans une requête :
1) il faut récrire la requête si l'on veut changer le comportement
2) cela empêche les mécanismes d'escalade de verrous qui améliore les
performances
Dans le principe tout code SQL devrait être séparé en 2 choses bien
distinctes :
d'un côté le code fonctionnel (INSERT, SELECT, UPDATE, DELETE)
de l'autre le code administratif ou technique : transaction, verrous,
index....
A +
Merci par avance.
"Fred BROUARD" a écrit dans le message de
groupe
de discussion : #Ch. a écrit :Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de
resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il
me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche
le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
évitez les tables temporaires et brecourrez à des tables fixe dans votre
base en ajoutant une colonne discriminant par utilisateur, par exemple
au
moyen du SPID.
A +
comment faire pour avoir du code commun à plusieurs SP ?
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
c'est ok je comprends
je compte commencer un code normalement pour voir le comportement, vu qu' il
y a quand meme des volumetrie asser importante.
j'aurais aimé gagné sur le delete.
car des le debut du process vu que les SPID peuvent etre réaffectés, il faut
que je commence par verifier la presence et si oui je delete.
c'est sur cette partie que j'aurais aimé gagné du temps.
est-ce que par defaut il bloque aux lignes insérées plutot que des pa ges ou
des tables ?
Ch.
"Fred BROUARD" a écrit dans le message dene ws:e$
> Ch. a écrit :
>> Fred j'ai une question
>> j'ai testé cette methode qui me plait plus que beaucoup.
>> Mais comment eviter des blocages ou des locks quand l'appli est fortem ent
>> sollicter, et avec des volumes qui peuvent etre consequent ???
> en principe il ne devrait pas y avoir de blocage car chaque utilisateur
> travaille sur un jeu de ligne différent. Néanmoins on peut forcer l e
> verrouillage de ligne en recréant l'index avec DISALLOW_PAGELOCK /
> ALLOW_ROWLOCK (attention, si nombreuses lignes impactées => nombreu x
> verrous ce qui encombre la mémoire) et même faire des lectures sale en
> repositionnant le niveau d'isolation à READ UNCOMMITTED
>> faut'il adopter preciser un type de verrou particulier lors de l'inser t ?
>> comment peux t'on accélérer le delete ?
> C'est une connerie que d'utiliser directement des tags de verrouillage
> dans une requête :
> 1) il faut récrire la requête si l'on veut changer le comportement
> 2) cela empêche les mécanismes d'escalade de verrous qui améliore les
> performances
> Dans le principe tout code SQL devrait être séparé en 2 choses bi en
> distinctes :
> d'un côté le code fonctionnel (INSERT, SELECT, UPDATE, DELETE)
> de l'autre le code administratif ou technique : transaction, verrous,
> index....
> A +
>> Merci par avance.
>> "Fred BROUARD" a écrit dans le message d e
>> groupe
>> de discussion : #
>>> Ch. a écrit :
>>>> Tres bizarre mais c'est apparemment une limitation de SQL 2005
>>>> en gros j'ai des procedures stockées (SP)
>>>> j'aimerais avoir du code commun partagées par plusieurs procedures .
>>>> Exemple
>>>> SP1 -> renvoi un jeu de resultats
>>>> SP2 -> appel SP1 qui place les resultats dans une table tempo que je
>>>> travaille dans le reste de SP2 pour afficher mon nouveau jeu de
>>>> resultats
>>>> issus de SP1
>>>> ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il
>>>> me
>>>> dit
>>>> Une instruction INSERT EXEC ne peut pas être imbriquée.
>>>> alors comment faire car repeter du code dans chaque procedure empech e
>>>> le
>>>> maintient et le suivi
>>>> car si je change une SPx je dois faire la partie commune de code dan s
>>>> toutes les autres si j'en connais le nom et l'existance surtout.
>>> évitez les tables temporaires et brecourrez à des tables fixe dan s votre
>>> base en ajoutant une colonne discriminant par utilisateur, par exempl e
>>> au
>>> moyen du SPID.
>>> A +
>>>> comment faire pour avoir du code commun à plusieurs SP ?
>>> --
>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et la ngage SQL
>>> Le site sur le langage SQL et les SGBDR : http://sqlpro.develop pez.com
>>> Audit, conseil, expertise, formation, modélisation, tuning, optimis ation
>>> Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Techn ologies
>>> ***********************http://www.sqlspot.com************************ *
> --
> Frédéric BROUARD, MVP SQL Server, expert bases de données et lang age SQL
> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpe z.com
> Audit, conseil, expertise, formation, modélisation, tuning, optimisat ion
> Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technol ogies
> ***********************http://www.sqlspot.com*************************
c'est ok je comprends
je compte commencer un code normalement pour voir le comportement, vu qu' il
y a quand meme des volumetrie asser importante.
j'aurais aimé gagné sur le delete.
car des le debut du process vu que les SPID peuvent etre réaffectés, il faut
que je commence par verifier la presence et si oui je delete.
c'est sur cette partie que j'aurais aimé gagné du temps.
est-ce que par defaut il bloque aux lignes insérées plutot que des pa ges ou
des tables ?
Ch.
"Fred BROUARD" <broua...@club-internet.fr> a écrit dans le message dene ws:e$fxP4olKHA.2160@TK2MSFTNGP02.phx.gbl...
> Ch. a écrit :
>> Fred j'ai une question
>> j'ai testé cette methode qui me plait plus que beaucoup.
>> Mais comment eviter des blocages ou des locks quand l'appli est fortem ent
>> sollicter, et avec des volumes qui peuvent etre consequent ???
> en principe il ne devrait pas y avoir de blocage car chaque utilisateur
> travaille sur un jeu de ligne différent. Néanmoins on peut forcer l e
> verrouillage de ligne en recréant l'index avec DISALLOW_PAGELOCK /
> ALLOW_ROWLOCK (attention, si nombreuses lignes impactées => nombreu x
> verrous ce qui encombre la mémoire) et même faire des lectures sale en
> repositionnant le niveau d'isolation à READ UNCOMMITTED
>> faut'il adopter preciser un type de verrou particulier lors de l'inser t ?
>> comment peux t'on accélérer le delete ?
> C'est une connerie que d'utiliser directement des tags de verrouillage
> dans une requête :
> 1) il faut récrire la requête si l'on veut changer le comportement
> 2) cela empêche les mécanismes d'escalade de verrous qui améliore les
> performances
> Dans le principe tout code SQL devrait être séparé en 2 choses bi en
> distinctes :
> d'un côté le code fonctionnel (INSERT, SELECT, UPDATE, DELETE)
> de l'autre le code administratif ou technique : transaction, verrous,
> index....
> A +
>> Merci par avance.
>> "Fred BROUARD" <broua...@club-internet.fr> a écrit dans le message d e
>> groupe
>> de discussion : #zLYYOKlKHA.6...@TK2MSFTNGP02.phx.gbl...
>>> Ch. a écrit :
>>>> Tres bizarre mais c'est apparemment une limitation de SQL 2005
>>>> en gros j'ai des procedures stockées (SP)
>>>> j'aimerais avoir du code commun partagées par plusieurs procedures .
>>>> Exemple
>>>> SP1 -> renvoi un jeu de resultats
>>>> SP2 -> appel SP1 qui place les resultats dans une table tempo que je
>>>> travaille dans le reste de SP2 pour afficher mon nouveau jeu de
>>>> resultats
>>>> issus de SP1
>>>> ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il
>>>> me
>>>> dit
>>>> Une instruction INSERT EXEC ne peut pas être imbriquée.
>>>> alors comment faire car repeter du code dans chaque procedure empech e
>>>> le
>>>> maintient et le suivi
>>>> car si je change une SPx je dois faire la partie commune de code dan s
>>>> toutes les autres si j'en connais le nom et l'existance surtout.
>>> évitez les tables temporaires et brecourrez à des tables fixe dan s votre
>>> base en ajoutant une colonne discriminant par utilisateur, par exempl e
>>> au
>>> moyen du SPID.
>>> A +
>>>> comment faire pour avoir du code commun à plusieurs SP ?
>>> --
>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et la ngage SQL
>>> Le site sur le langage SQL et les SGBDR : http://sqlpro.develop pez.com
>>> Audit, conseil, expertise, formation, modélisation, tuning, optimis ation
>>> Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Techn ologies
>>> ***********************http://www.sqlspot.com************************ *
> --
> Frédéric BROUARD, MVP SQL Server, expert bases de données et lang age SQL
> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpe z.com
> Audit, conseil, expertise, formation, modélisation, tuning, optimisat ion
> Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technol ogies
> ***********************http://www.sqlspot.com*************************
c'est ok je comprends
je compte commencer un code normalement pour voir le comportement, vu qu' il
y a quand meme des volumetrie asser importante.
j'aurais aimé gagné sur le delete.
car des le debut du process vu que les SPID peuvent etre réaffectés, il faut
que je commence par verifier la presence et si oui je delete.
c'est sur cette partie que j'aurais aimé gagné du temps.
est-ce que par defaut il bloque aux lignes insérées plutot que des pa ges ou
des tables ?
Ch.
"Fred BROUARD" a écrit dans le message dene ws:e$
> Ch. a écrit :
>> Fred j'ai une question
>> j'ai testé cette methode qui me plait plus que beaucoup.
>> Mais comment eviter des blocages ou des locks quand l'appli est fortem ent
>> sollicter, et avec des volumes qui peuvent etre consequent ???
> en principe il ne devrait pas y avoir de blocage car chaque utilisateur
> travaille sur un jeu de ligne différent. Néanmoins on peut forcer l e
> verrouillage de ligne en recréant l'index avec DISALLOW_PAGELOCK /
> ALLOW_ROWLOCK (attention, si nombreuses lignes impactées => nombreu x
> verrous ce qui encombre la mémoire) et même faire des lectures sale en
> repositionnant le niveau d'isolation à READ UNCOMMITTED
>> faut'il adopter preciser un type de verrou particulier lors de l'inser t ?
>> comment peux t'on accélérer le delete ?
> C'est une connerie que d'utiliser directement des tags de verrouillage
> dans une requête :
> 1) il faut récrire la requête si l'on veut changer le comportement
> 2) cela empêche les mécanismes d'escalade de verrous qui améliore les
> performances
> Dans le principe tout code SQL devrait être séparé en 2 choses bi en
> distinctes :
> d'un côté le code fonctionnel (INSERT, SELECT, UPDATE, DELETE)
> de l'autre le code administratif ou technique : transaction, verrous,
> index....
> A +
>> Merci par avance.
>> "Fred BROUARD" a écrit dans le message d e
>> groupe
>> de discussion : #
>>> Ch. a écrit :
>>>> Tres bizarre mais c'est apparemment une limitation de SQL 2005
>>>> en gros j'ai des procedures stockées (SP)
>>>> j'aimerais avoir du code commun partagées par plusieurs procedures .
>>>> Exemple
>>>> SP1 -> renvoi un jeu de resultats
>>>> SP2 -> appel SP1 qui place les resultats dans une table tempo que je
>>>> travaille dans le reste de SP2 pour afficher mon nouveau jeu de
>>>> resultats
>>>> issus de SP1
>>>> ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il
>>>> me
>>>> dit
>>>> Une instruction INSERT EXEC ne peut pas être imbriquée.
>>>> alors comment faire car repeter du code dans chaque procedure empech e
>>>> le
>>>> maintient et le suivi
>>>> car si je change une SPx je dois faire la partie commune de code dan s
>>>> toutes les autres si j'en connais le nom et l'existance surtout.
>>> évitez les tables temporaires et brecourrez à des tables fixe dan s votre
>>> base en ajoutant une colonne discriminant par utilisateur, par exempl e
>>> au
>>> moyen du SPID.
>>> A +
>>>> comment faire pour avoir du code commun à plusieurs SP ?
>>> --
>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et la ngage SQL
>>> Le site sur le langage SQL et les SGBDR : http://sqlpro.develop pez.com
>>> Audit, conseil, expertise, formation, modélisation, tuning, optimis ation
>>> Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Techn ologies
>>> ***********************http://www.sqlspot.com************************ *
> --
> Frédéric BROUARD, MVP SQL Server, expert bases de données et lang age SQL
> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpe z.com
> Audit, conseil, expertise, formation, modélisation, tuning, optimisat ion
> Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technol ogies
> ***********************http://www.sqlspot.com*************************
En sql server par défaut le lock est la ligne, ou la clé d'index, cela
permet de verrouiller le moins de ressource et offre un bon niveau
concurrence.
Mais comme/quand, il y a bcp de verrou ca peut ralentir ta requête,
pour éviter cela sql server évalue le nombre de ligne a traiter et
peux changer convertir des verrous en granularité plus large. Ce qui
limite les pertes de temps de la pose de chaque verrou. Et je pense
que cette méthode s'appelle l'escalade des verrous. mais si mes
souvenirs sont bon, il y a une fonction system
sys.dm_db_index_opartianal_states() qui permet de voir pas mal
d'information.
Donc il faut mieux suivre les conseils de notre gourou Fred SQL,
et je laisserais gérer sql server ces verrou....Mais je me pose une
question dans quel cas il faut jouter DISALLOW_PAGELOCK /
ALLOW_ROWLOCK pour gagner des performances.
On 18 jan, 12:31, "Ch." wrote:c'est ok je comprends
je compte commencer un code normalement pour voir le comportement, vu qu'il
y a quand meme des volumetrie asser importante.
j'aurais aimé gagné sur le delete.
car des le debut du process vu que les SPID peuvent etre réaffectés, il faut
que je commence par verifier la presence et si oui je delete.
c'est sur cette partie que j'aurais aimé gagné du temps.
est-ce que par defaut il bloque aux lignes insérées plutot que des pages ou
des tables ?
Ch.
"Fred BROUARD" a écrit dans le message denews:e$Ch. a écrit :Fred j'ai une question
j'ai testé cette methode qui me plait plus que beaucoup.
Mais comment eviter des blocages ou des locks quand l'appli est fortement
sollicter, et avec des volumes qui peuvent etre consequent ???
en principe il ne devrait pas y avoir de blocage car chaque utilisateur
travaille sur un jeu de ligne différent. Néanmoins on peut forcer le
verrouillage de ligne en recréant l'index avec DISALLOW_PAGELOCK /
ALLOW_ROWLOCK (attention, si nombreuses lignes impactées => nombreux
verrous ce qui encombre la mémoire) et même faire des lectures sale en
repositionnant le niveau d'isolation à READ UNCOMMITTEDfaut'il adopter preciser un type de verrou particulier lors de l'insert ?
comment peux t'on accélérer le delete ?
C'est une connerie que d'utiliser directement des tags de verrouillage
dans une requête :
1) il faut récrire la requête si l'on veut changer le comportement
2) cela empêche les mécanismes d'escalade de verrous qui améliore les
performances
Dans le principe tout code SQL devrait être séparé en 2 choses bien
distinctes :
d'un côté le code fonctionnel (INSERT, SELECT, UPDATE, DELETE)
de l'autre le code administratif ou technique : transaction, verrous,
index....
A +Merci par avance.
"Fred BROUARD" a écrit dans le message de
groupe
de discussion : #Ch. a écrit :Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de
resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il
me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche
le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
évitez les tables temporaires et brecourrez à des tables fixe dans votre
base en ajoutant une colonne discriminant par utilisateur, par exemple
au
moyen du SPID.
A +comment faire pour avoir du code commun à plusieurs SP ?
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
***********************http://www.sqlspot.com*************************
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
***********************http://www.sqlspot.com*************************
En sql server par défaut le lock est la ligne, ou la clé d'index, cela
permet de verrouiller le moins de ressource et offre un bon niveau
concurrence.
Mais comme/quand, il y a bcp de verrou ca peut ralentir ta requête,
pour éviter cela sql server évalue le nombre de ligne a traiter et
peux changer convertir des verrous en granularité plus large. Ce qui
limite les pertes de temps de la pose de chaque verrou. Et je pense
que cette méthode s'appelle l'escalade des verrous. mais si mes
souvenirs sont bon, il y a une fonction system
sys.dm_db_index_opartianal_states() qui permet de voir pas mal
d'information.
Donc il faut mieux suivre les conseils de notre gourou Fred SQL,
et je laisserais gérer sql server ces verrou....Mais je me pose une
question dans quel cas il faut jouter DISALLOW_PAGELOCK /
ALLOW_ROWLOCK pour gagner des performances.
On 18 jan, 12:31, "Ch." <christophe.pe...@pjms.fr> wrote:
c'est ok je comprends
je compte commencer un code normalement pour voir le comportement, vu qu'il
y a quand meme des volumetrie asser importante.
j'aurais aimé gagné sur le delete.
car des le debut du process vu que les SPID peuvent etre réaffectés, il faut
que je commence par verifier la presence et si oui je delete.
c'est sur cette partie que j'aurais aimé gagné du temps.
est-ce que par defaut il bloque aux lignes insérées plutot que des pages ou
des tables ?
Ch.
"Fred BROUARD" <broua...@club-internet.fr> a écrit dans le message denews:e$fxP4olKHA.2160@TK2MSFTNGP02.phx.gbl...
Ch. a écrit :
Fred j'ai une question
j'ai testé cette methode qui me plait plus que beaucoup.
Mais comment eviter des blocages ou des locks quand l'appli est fortement
sollicter, et avec des volumes qui peuvent etre consequent ???
en principe il ne devrait pas y avoir de blocage car chaque utilisateur
travaille sur un jeu de ligne différent. Néanmoins on peut forcer le
verrouillage de ligne en recréant l'index avec DISALLOW_PAGELOCK /
ALLOW_ROWLOCK (attention, si nombreuses lignes impactées => nombreux
verrous ce qui encombre la mémoire) et même faire des lectures sale en
repositionnant le niveau d'isolation à READ UNCOMMITTED
faut'il adopter preciser un type de verrou particulier lors de l'insert ?
comment peux t'on accélérer le delete ?
C'est une connerie que d'utiliser directement des tags de verrouillage
dans une requête :
1) il faut récrire la requête si l'on veut changer le comportement
2) cela empêche les mécanismes d'escalade de verrous qui améliore les
performances
Dans le principe tout code SQL devrait être séparé en 2 choses bien
distinctes :
d'un côté le code fonctionnel (INSERT, SELECT, UPDATE, DELETE)
de l'autre le code administratif ou technique : transaction, verrous,
index....
A +
Merci par avance.
"Fred BROUARD" <broua...@club-internet.fr> a écrit dans le message de
groupe
de discussion : #zLYYOKlKHA.6...@TK2MSFTNGP02.phx.gbl...
Ch. a écrit :
Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de
resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il
me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche
le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
évitez les tables temporaires et brecourrez à des tables fixe dans votre
base en ajoutant une colonne discriminant par utilisateur, par exemple
au
moyen du SPID.
A +
comment faire pour avoir du code commun à plusieurs SP ?
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
***********************http://www.sqlspot.com*************************
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
***********************http://www.sqlspot.com*************************
En sql server par défaut le lock est la ligne, ou la clé d'index, cela
permet de verrouiller le moins de ressource et offre un bon niveau
concurrence.
Mais comme/quand, il y a bcp de verrou ca peut ralentir ta requête,
pour éviter cela sql server évalue le nombre de ligne a traiter et
peux changer convertir des verrous en granularité plus large. Ce qui
limite les pertes de temps de la pose de chaque verrou. Et je pense
que cette méthode s'appelle l'escalade des verrous. mais si mes
souvenirs sont bon, il y a une fonction system
sys.dm_db_index_opartianal_states() qui permet de voir pas mal
d'information.
Donc il faut mieux suivre les conseils de notre gourou Fred SQL,
et je laisserais gérer sql server ces verrou....Mais je me pose une
question dans quel cas il faut jouter DISALLOW_PAGELOCK /
ALLOW_ROWLOCK pour gagner des performances.
On 18 jan, 12:31, "Ch." wrote:c'est ok je comprends
je compte commencer un code normalement pour voir le comportement, vu qu'il
y a quand meme des volumetrie asser importante.
j'aurais aimé gagné sur le delete.
car des le debut du process vu que les SPID peuvent etre réaffectés, il faut
que je commence par verifier la presence et si oui je delete.
c'est sur cette partie que j'aurais aimé gagné du temps.
est-ce que par defaut il bloque aux lignes insérées plutot que des pages ou
des tables ?
Ch.
"Fred BROUARD" a écrit dans le message denews:e$Ch. a écrit :Fred j'ai une question
j'ai testé cette methode qui me plait plus que beaucoup.
Mais comment eviter des blocages ou des locks quand l'appli est fortement
sollicter, et avec des volumes qui peuvent etre consequent ???
en principe il ne devrait pas y avoir de blocage car chaque utilisateur
travaille sur un jeu de ligne différent. Néanmoins on peut forcer le
verrouillage de ligne en recréant l'index avec DISALLOW_PAGELOCK /
ALLOW_ROWLOCK (attention, si nombreuses lignes impactées => nombreux
verrous ce qui encombre la mémoire) et même faire des lectures sale en
repositionnant le niveau d'isolation à READ UNCOMMITTEDfaut'il adopter preciser un type de verrou particulier lors de l'insert ?
comment peux t'on accélérer le delete ?
C'est une connerie que d'utiliser directement des tags de verrouillage
dans une requête :
1) il faut récrire la requête si l'on veut changer le comportement
2) cela empêche les mécanismes d'escalade de verrous qui améliore les
performances
Dans le principe tout code SQL devrait être séparé en 2 choses bien
distinctes :
d'un côté le code fonctionnel (INSERT, SELECT, UPDATE, DELETE)
de l'autre le code administratif ou technique : transaction, verrous,
index....
A +Merci par avance.
"Fred BROUARD" a écrit dans le message de
groupe
de discussion : #Ch. a écrit :Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de
resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il
me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche
le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
évitez les tables temporaires et brecourrez à des tables fixe dans votre
base en ajoutant une colonne discriminant par utilisateur, par exemple
au
moyen du SPID.
A +comment faire pour avoir du code commun à plusieurs SP ?
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
***********************http://www.sqlspot.com*************************
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
***********************http://www.sqlspot.com*************************
zoltix a écrit :En sql server par défaut le lock est la ligne, ou la clé d'index, cela
permet de verrouiller le moins de ressource et offre un bon niveau
concurrence.
Mais comme/quand, il y a bcp de verrou ca peut ralentir ta requête,
pour éviter cela sql server évalue le nombre de ligne a traiter et
peux changer convertir des verrous en granularité plus large. Ce qui
limite les pertes de temps de la pose de chaque verrou. Et je pense
que cette méthode s'appelle l'escalade des verrous. mais si mes
souvenirs sont bon, il y a une fonction system
sys.dm_db_index_opartianal_states() qui permet de voir pas mal
d'information.
Donc il faut mieux suivre les conseils de notre gourou Fred SQL,
et je laisserais gérer sql server ces verrou....Mais je me pose une
question dans quel cas il faut jouter DISALLOW_PAGELOCK /
ALLOW_ROWLOCK pour gagner des performances.
quand on est certains que toutes les requêtes sur cette table sont
similaire en cardinalité.
Par exemple un de mes amis, hélas décédé l'an dernier faisait des
application de salle de marché bancaire et bien entendu, l'essentiel des
requêtes portait sur une action et sa valeur, donc une ligne. SQL Server
2000 ayant tendance à faire du verrouillage de page, il m'avait demandé
conseil, et par le biais de sp_indexoption on a interdit le verrouillage
de page et forcé le verrouillage de ligne.
La montée en charge fut meilleure, mais...
Peu après le nombre de verrous explosait et il fallait réserver plus
d'espace au pool de verrous ce que nous fîmes en modifiant sp_configure.
Mais...
Peu après, c'est le nombre d'objet ouvert qui était trop juste !
Alors nous avons modifié un 2e paramètre dans le sp_configure (open
objects de mémoire).
Cela pour vous dire que les conséquences de ne pas laisser faire le moteur
SQL, sont parfois complexes et peuvent agir dans le sens contraire à celui
voulu !
A +
On 18 jan, 12:31, "Ch." wrote:c'est ok je comprends
je compte commencer un code normalement pour voir le comportement, vu
qu'il
y a quand meme des volumetrie asser importante.
j'aurais aimé gagné sur le delete.
car des le debut du process vu que les SPID peuvent etre réaffectés, il
faut
que je commence par verifier la presence et si oui je delete.
c'est sur cette partie que j'aurais aimé gagné du temps.
est-ce que par defaut il bloque aux lignes insérées plutot que des pages
ou
des tables ?
Ch.
"Fred BROUARD" a écrit dans le message
denews:e$Ch. a écrit :Fred j'ai une question
j'ai testé cette methode qui me plait plus que beaucoup.
Mais comment eviter des blocages ou des locks quand l'appli est
fortement
sollicter, et avec des volumes qui peuvent etre consequent ???
en principe il ne devrait pas y avoir de blocage car chaque utilisateur
travaille sur un jeu de ligne différent. Néanmoins on peut forcer le
verrouillage de ligne en recréant l'index avec DISALLOW_PAGELOCK /
ALLOW_ROWLOCK (attention, si nombreuses lignes impactées => nombreux
verrous ce qui encombre la mémoire) et même faire des lectures sale en
repositionnant le niveau d'isolation à READ UNCOMMITTEDfaut'il adopter preciser un type de verrou particulier lors de
l'insert ?
comment peux t'on accélérer le delete ?
C'est une connerie que d'utiliser directement des tags de verrouillage
dans une requête :
1) il faut récrire la requête si l'on veut changer le comportement
2) cela empêche les mécanismes d'escalade de verrous qui améliore les
performances
Dans le principe tout code SQL devrait être séparé en 2 choses bien
distinctes :
d'un côté le code fonctionnel (INSERT, SELECT, UPDATE, DELETE)
de l'autre le code administratif ou technique : transaction, verrous,
index....
A +Merci par avance.
"Fred BROUARD" a écrit dans le message de
groupe
de discussion : #Ch. a écrit :Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que
je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de
resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas
il
me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure
empeche
le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code
dans
toutes les autres si j'en connais le nom et l'existance surtout.
évitez les tables temporaires et brecourrez à des tables fixe dans
votre
base en ajoutant une colonne discriminant par utilisateur, par
exemple
au
moyen du SPID.
A +comment faire pour avoir du code commun à plusieurs SP ?
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var
Technologies
***********************http://www.sqlspot.com*************************
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var
Technologies
***********************http://www.sqlspot.com*************************
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
zoltix a écrit :
En sql server par défaut le lock est la ligne, ou la clé d'index, cela
permet de verrouiller le moins de ressource et offre un bon niveau
concurrence.
Mais comme/quand, il y a bcp de verrou ca peut ralentir ta requête,
pour éviter cela sql server évalue le nombre de ligne a traiter et
peux changer convertir des verrous en granularité plus large. Ce qui
limite les pertes de temps de la pose de chaque verrou. Et je pense
que cette méthode s'appelle l'escalade des verrous. mais si mes
souvenirs sont bon, il y a une fonction system
sys.dm_db_index_opartianal_states() qui permet de voir pas mal
d'information.
Donc il faut mieux suivre les conseils de notre gourou Fred SQL,
et je laisserais gérer sql server ces verrou....Mais je me pose une
question dans quel cas il faut jouter DISALLOW_PAGELOCK /
ALLOW_ROWLOCK pour gagner des performances.
quand on est certains que toutes les requêtes sur cette table sont
similaire en cardinalité.
Par exemple un de mes amis, hélas décédé l'an dernier faisait des
application de salle de marché bancaire et bien entendu, l'essentiel des
requêtes portait sur une action et sa valeur, donc une ligne. SQL Server
2000 ayant tendance à faire du verrouillage de page, il m'avait demandé
conseil, et par le biais de sp_indexoption on a interdit le verrouillage
de page et forcé le verrouillage de ligne.
La montée en charge fut meilleure, mais...
Peu après le nombre de verrous explosait et il fallait réserver plus
d'espace au pool de verrous ce que nous fîmes en modifiant sp_configure.
Mais...
Peu après, c'est le nombre d'objet ouvert qui était trop juste !
Alors nous avons modifié un 2e paramètre dans le sp_configure (open
objects de mémoire).
Cela pour vous dire que les conséquences de ne pas laisser faire le moteur
SQL, sont parfois complexes et peuvent agir dans le sens contraire à celui
voulu !
A +
On 18 jan, 12:31, "Ch." <christophe.pe...@pjms.fr> wrote:
c'est ok je comprends
je compte commencer un code normalement pour voir le comportement, vu
qu'il
y a quand meme des volumetrie asser importante.
j'aurais aimé gagné sur le delete.
car des le debut du process vu que les SPID peuvent etre réaffectés, il
faut
que je commence par verifier la presence et si oui je delete.
c'est sur cette partie que j'aurais aimé gagné du temps.
est-ce que par defaut il bloque aux lignes insérées plutot que des pages
ou
des tables ?
Ch.
"Fred BROUARD" <broua...@club-internet.fr> a écrit dans le message
denews:e$fxP4olKHA.2160@TK2MSFTNGP02.phx.gbl...
Ch. a écrit :
Fred j'ai une question
j'ai testé cette methode qui me plait plus que beaucoup.
Mais comment eviter des blocages ou des locks quand l'appli est
fortement
sollicter, et avec des volumes qui peuvent etre consequent ???
en principe il ne devrait pas y avoir de blocage car chaque utilisateur
travaille sur un jeu de ligne différent. Néanmoins on peut forcer le
verrouillage de ligne en recréant l'index avec DISALLOW_PAGELOCK /
ALLOW_ROWLOCK (attention, si nombreuses lignes impactées => nombreux
verrous ce qui encombre la mémoire) et même faire des lectures sale en
repositionnant le niveau d'isolation à READ UNCOMMITTED
faut'il adopter preciser un type de verrou particulier lors de
l'insert ?
comment peux t'on accélérer le delete ?
C'est une connerie que d'utiliser directement des tags de verrouillage
dans une requête :
1) il faut récrire la requête si l'on veut changer le comportement
2) cela empêche les mécanismes d'escalade de verrous qui améliore les
performances
Dans le principe tout code SQL devrait être séparé en 2 choses bien
distinctes :
d'un côté le code fonctionnel (INSERT, SELECT, UPDATE, DELETE)
de l'autre le code administratif ou technique : transaction, verrous,
index....
A +
Merci par avance.
"Fred BROUARD" <broua...@club-internet.fr> a écrit dans le message de
groupe
de discussion : #zLYYOKlKHA.6...@TK2MSFTNGP02.phx.gbl...
Ch. a écrit :
Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que
je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de
resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas
il
me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure
empeche
le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code
dans
toutes les autres si j'en connais le nom et l'existance surtout.
évitez les tables temporaires et brecourrez à des tables fixe dans
votre
base en ajoutant une colonne discriminant par utilisateur, par
exemple
au
moyen du SPID.
A +
comment faire pour avoir du code commun à plusieurs SP ?
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var
Technologies
***********************http://www.sqlspot.com*************************
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var
Technologies
***********************http://www.sqlspot.com*************************
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
zoltix a écrit :En sql server par défaut le lock est la ligne, ou la clé d'index, cela
permet de verrouiller le moins de ressource et offre un bon niveau
concurrence.
Mais comme/quand, il y a bcp de verrou ca peut ralentir ta requête,
pour éviter cela sql server évalue le nombre de ligne a traiter et
peux changer convertir des verrous en granularité plus large. Ce qui
limite les pertes de temps de la pose de chaque verrou. Et je pense
que cette méthode s'appelle l'escalade des verrous. mais si mes
souvenirs sont bon, il y a une fonction system
sys.dm_db_index_opartianal_states() qui permet de voir pas mal
d'information.
Donc il faut mieux suivre les conseils de notre gourou Fred SQL,
et je laisserais gérer sql server ces verrou....Mais je me pose une
question dans quel cas il faut jouter DISALLOW_PAGELOCK /
ALLOW_ROWLOCK pour gagner des performances.
quand on est certains que toutes les requêtes sur cette table sont
similaire en cardinalité.
Par exemple un de mes amis, hélas décédé l'an dernier faisait des
application de salle de marché bancaire et bien entendu, l'essentiel des
requêtes portait sur une action et sa valeur, donc une ligne. SQL Server
2000 ayant tendance à faire du verrouillage de page, il m'avait demandé
conseil, et par le biais de sp_indexoption on a interdit le verrouillage
de page et forcé le verrouillage de ligne.
La montée en charge fut meilleure, mais...
Peu après le nombre de verrous explosait et il fallait réserver plus
d'espace au pool de verrous ce que nous fîmes en modifiant sp_configure.
Mais...
Peu après, c'est le nombre d'objet ouvert qui était trop juste !
Alors nous avons modifié un 2e paramètre dans le sp_configure (open
objects de mémoire).
Cela pour vous dire que les conséquences de ne pas laisser faire le moteur
SQL, sont parfois complexes et peuvent agir dans le sens contraire à celui
voulu !
A +
On 18 jan, 12:31, "Ch." wrote:c'est ok je comprends
je compte commencer un code normalement pour voir le comportement, vu
qu'il
y a quand meme des volumetrie asser importante.
j'aurais aimé gagné sur le delete.
car des le debut du process vu que les SPID peuvent etre réaffectés, il
faut
que je commence par verifier la presence et si oui je delete.
c'est sur cette partie que j'aurais aimé gagné du temps.
est-ce que par defaut il bloque aux lignes insérées plutot que des pages
ou
des tables ?
Ch.
"Fred BROUARD" a écrit dans le message
denews:e$Ch. a écrit :Fred j'ai une question
j'ai testé cette methode qui me plait plus que beaucoup.
Mais comment eviter des blocages ou des locks quand l'appli est
fortement
sollicter, et avec des volumes qui peuvent etre consequent ???
en principe il ne devrait pas y avoir de blocage car chaque utilisateur
travaille sur un jeu de ligne différent. Néanmoins on peut forcer le
verrouillage de ligne en recréant l'index avec DISALLOW_PAGELOCK /
ALLOW_ROWLOCK (attention, si nombreuses lignes impactées => nombreux
verrous ce qui encombre la mémoire) et même faire des lectures sale en
repositionnant le niveau d'isolation à READ UNCOMMITTEDfaut'il adopter preciser un type de verrou particulier lors de
l'insert ?
comment peux t'on accélérer le delete ?
C'est une connerie que d'utiliser directement des tags de verrouillage
dans une requête :
1) il faut récrire la requête si l'on veut changer le comportement
2) cela empêche les mécanismes d'escalade de verrous qui améliore les
performances
Dans le principe tout code SQL devrait être séparé en 2 choses bien
distinctes :
d'un côté le code fonctionnel (INSERT, SELECT, UPDATE, DELETE)
de l'autre le code administratif ou technique : transaction, verrous,
index....
A +Merci par avance.
"Fred BROUARD" a écrit dans le message de
groupe
de discussion : #Ch. a écrit :Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que
je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de
resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas
il
me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure
empeche
le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code
dans
toutes les autres si j'en connais le nom et l'existance surtout.
évitez les tables temporaires et brecourrez à des tables fixe dans
votre
base en ajoutant une colonne discriminant par utilisateur, par
exemple
au
moyen du SPID.
A +comment faire pour avoir du code commun à plusieurs SP ?
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var
Technologies
***********************http://www.sqlspot.com*************************
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var
Technologies
***********************http://www.sqlspot.com*************************
--
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
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
comment faire pour avoir du code commun à plusieurs SP ?
Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
comment faire pour avoir du code commun à plusieurs SP ?
Tres bizarre mais c'est apparemment une limitation de SQL 2005
en gros j'ai des procedures stockées (SP)
j'aimerais avoir du code commun partagées par plusieurs procedures.
Exemple
SP1 -> renvoi un jeu de resultats
SP2 -> appel SP1 qui place les resultats dans une table tempo que je
travaille dans le reste de SP2 pour afficher mon nouveau jeu de resultats
issus de SP1
ben si je veux faire pareil avec SP3 -> qui appel SP2 ca marche pas il me
dit
Une instruction INSERT EXEC ne peut pas être imbriquée.
alors comment faire car repeter du code dans chaque procedure empeche le
maintient et le suivi
car si je change une SPx je dois faire la partie commune de code dans
toutes les autres si j'en connais le nom et l'existance surtout.
comment faire pour avoir du code commun à plusieurs SP ?