pb constaté sur édition développeur sp2 cu6.
après création d'une vue indexé (complexité moyenne).
Les actions d'insert dans une table faisant partie de la vue indexé,
entraine lorsque cette action est effectué dans un procédure stockée, la
lecture compléte de la vue indexé, bien que celle ci ne soit pas appelé lors
de l'insert. Le plan d'éxécution montre bien l'insert unitaire et le parcours
complet de la vue indexé.
Si l'action insert est effectué sur la même table à partir d'un script SQL
via management studio le plan d'éxécution ne prend pas en compte la dite vue
indexé.
Est ce que le comportement dans la procédure stockée est normal ?
ps: la requête d'insertion est de la plus simple expression
INSERT laTAble (col1, col2) values(1,'valeur');
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
bruno reiter
C'est le comportement normal, une MaJ des tables sous-jacentes provoque la MaJ de la vue.
BR
"Leon" wrote in message news:
bonjour,
pb constaté sur édition développeur sp2 cu6. après création d'une vue indexé (complexité moyenne). Les actions d'insert dans une table faisant partie de la vue indexé, entraine lorsque cette action est effectué dans un procédure stockée, la lecture compléte de la vue indexé, bien que celle ci ne soit pas appelé lors de l'insert. Le plan d'éxécution montre bien l'insert unitaire et le parcours complet de la vue indexé.
Si l'action insert est effectué sur la même table à partir d'un script SQL via management studio le plan d'éxécution ne prend pas en compte la dite vue indexé.
Est ce que le comportement dans la procédure stockée est normal ?
ps: la requête d'insertion est de la plus simple expression INSERT laTAble (col1, col2) values(1,'valeur');
C'est le comportement normal, une MaJ des tables sous-jacentes provoque la
MaJ de la vue.
BR
"Leon" <Leon@discussions.microsoft.com> wrote in message
news:3CC6B9FF-1060-4891-B9D9-B41F0BC53037@microsoft.com...
bonjour,
pb constaté sur édition développeur sp2 cu6.
après création d'une vue indexé (complexité moyenne).
Les actions d'insert dans une table faisant partie de la vue indexé,
entraine lorsque cette action est effectué dans un procédure stockée, la
lecture compléte de la vue indexé, bien que celle ci ne soit pas appelé
lors
de l'insert. Le plan d'éxécution montre bien l'insert unitaire et le
parcours
complet de la vue indexé.
Si l'action insert est effectué sur la même table à partir d'un script SQL
via management studio le plan d'éxécution ne prend pas en compte la dite
vue
indexé.
Est ce que le comportement dans la procédure stockée est normal ?
ps: la requête d'insertion est de la plus simple expression
INSERT laTAble (col1, col2) values(1,'valeur');
C'est le comportement normal, une MaJ des tables sous-jacentes provoque la MaJ de la vue.
BR
"Leon" wrote in message news:
bonjour,
pb constaté sur édition développeur sp2 cu6. après création d'une vue indexé (complexité moyenne). Les actions d'insert dans une table faisant partie de la vue indexé, entraine lorsque cette action est effectué dans un procédure stockée, la lecture compléte de la vue indexé, bien que celle ci ne soit pas appelé lors de l'insert. Le plan d'éxécution montre bien l'insert unitaire et le parcours complet de la vue indexé.
Si l'action insert est effectué sur la même table à partir d'un script SQL via management studio le plan d'éxécution ne prend pas en compte la dite vue indexé.
Est ce que le comportement dans la procédure stockée est normal ?
ps: la requête d'insertion est de la plus simple expression INSERT laTAble (col1, col2) values(1,'valeur');
Leon
merci pour la réponse. Quelle serait les raisons qui font que l'insert via script SQL ne passe pas par la vue et le même insert dans une procédure stockée déclenche la maj de l'index de la vue ? Est ce qu'il peut s'agir d'un bug ou d'une option mal positionnée ?
"bruno reiter" a écrit :
C'est le comportement normal, une MaJ des tables sous-jacentes provoque la MaJ de la vue.
BR
"Leon" wrote in message news: > bonjour, > > pb constaté sur édition développeur sp2 cu6. > après création d'une vue indexé (complexité moyenne). > Les actions d'insert dans une table faisant partie de la vue indexé, > entraine lorsque cette action est effectué dans un procédure stockée, la > lecture compléte de la vue indexé, bien que celle ci ne soit pas appelé > lors > de l'insert. Le plan d'éxécution montre bien l'insert unitaire et le > parcours > complet de la vue indexé. > > Si l'action insert est effectué sur la même table à partir d'un script SQL > via management studio le plan d'éxécution ne prend pas en compte la dite > vue > indexé. > > Est ce que le comportement dans la procédure stockée est normal ? > > > ps: la requête d'insertion est de la plus simple expression > INSERT laTAble (col1, col2) values(1,'valeur'); >
merci pour la réponse.
Quelle serait les raisons qui font que l'insert via script SQL ne passe pas
par la vue et le même insert dans une procédure stockée déclenche la maj de
l'index de la vue ?
Est ce qu'il peut s'agir d'un bug ou d'une option mal positionnée ?
"bruno reiter" a écrit :
C'est le comportement normal, une MaJ des tables sous-jacentes provoque la
MaJ de la vue.
BR
"Leon" <Leon@discussions.microsoft.com> wrote in message
news:3CC6B9FF-1060-4891-B9D9-B41F0BC53037@microsoft.com...
> bonjour,
>
> pb constaté sur édition développeur sp2 cu6.
> après création d'une vue indexé (complexité moyenne).
> Les actions d'insert dans une table faisant partie de la vue indexé,
> entraine lorsque cette action est effectué dans un procédure stockée, la
> lecture compléte de la vue indexé, bien que celle ci ne soit pas appelé
> lors
> de l'insert. Le plan d'éxécution montre bien l'insert unitaire et le
> parcours
> complet de la vue indexé.
>
> Si l'action insert est effectué sur la même table à partir d'un script SQL
> via management studio le plan d'éxécution ne prend pas en compte la dite
> vue
> indexé.
>
> Est ce que le comportement dans la procédure stockée est normal ?
>
>
> ps: la requête d'insertion est de la plus simple expression
> INSERT laTAble (col1, col2) values(1,'valeur');
>
merci pour la réponse. Quelle serait les raisons qui font que l'insert via script SQL ne passe pas par la vue et le même insert dans une procédure stockée déclenche la maj de l'index de la vue ? Est ce qu'il peut s'agir d'un bug ou d'une option mal positionnée ?
"bruno reiter" a écrit :
C'est le comportement normal, une MaJ des tables sous-jacentes provoque la MaJ de la vue.
BR
"Leon" wrote in message news: > bonjour, > > pb constaté sur édition développeur sp2 cu6. > après création d'une vue indexé (complexité moyenne). > Les actions d'insert dans une table faisant partie de la vue indexé, > entraine lorsque cette action est effectué dans un procédure stockée, la > lecture compléte de la vue indexé, bien que celle ci ne soit pas appelé > lors > de l'insert. Le plan d'éxécution montre bien l'insert unitaire et le > parcours > complet de la vue indexé. > > Si l'action insert est effectué sur la même table à partir d'un script SQL > via management studio le plan d'éxécution ne prend pas en compte la dite > vue > indexé. > > Est ce que le comportement dans la procédure stockée est normal ? > > > ps: la requête d'insertion est de la plus simple expression > INSERT laTAble (col1, col2) values(1,'valeur'); >
SQLpro
Il y a des chances que ce soit l'absence de spécification du schéma SQL dans votre INSERT qui en soit la cause.
En effet en l'absence de précision du schéma SQL, le compilateur ne sait quelle table ou vue il doit invoquer et recherche celle-ci dans les différents schéma. Ce qui provoque la recompilation et peut générer des plans d'exécution a moitié finis.
A +
***
Frédéric BROUARD - SQLpro - MVP SQL Server Spécialiste SQL/BD modélisation de données SQL & SGBDR http://sqlpro.developpez.com/ Expert SQL Server : http://www.sqlspot.com audits - optimisation - tuning - formation
On 9 oct, 13:04, Leon wrote:
merci pour la réponse. Quelle serait les raisons qui font que l'insert via script SQL ne passe p as par la vue et le même insert dans une procédure stockée déclenche la maj de l'index de la vue ? Est ce qu'il peut s'agir d'un bug ou d'une option mal positionnée ?
"bruno reiter" a écrit :
> C'est le comportement normal, une MaJ des tables sous-jacentes provoque la > MaJ de la vue.
> BR
> "Leon" wrote in message >news: > > bonjour,
> > pb constaté sur édition développeur sp2 cu6. > > après création d'une vue indexé (complexité moyenne). > > Les actions d'insert dans une table faisant partie de la vue indexé , > > entraine lorsque cette action est effectué dans un procédure stoc kée, la > > lecture compléte de la vue indexé, bien que celle ci ne soit pas appelé > > lors > > de l'insert. Le plan d'éxécution montre bien l'insert unitaire et le > > parcours > > complet de la vue indexé.
> > Si l'action insert est effectué sur la même table à partir d'un script SQL > > via management studio le plan d'éxécution ne prend pas en compte la dite > > vue > > indexé.
> > Est ce que le comportement dans la procédure stockée est normal ?
> > ps: la requête d'insertion est de la plus simple expression > > INSERT laTAble (col1, col2) values(1,'valeur');
Il y a des chances que ce soit l'absence de spécification du schéma
SQL dans votre INSERT qui en soit la cause.
En effet en l'absence de précision du schéma SQL, le compilateur ne
sait quelle table ou vue il doit invoquer et recherche celle-ci dans
les différents schéma. Ce qui provoque la recompilation et peut
générer des plans d'exécution a moitié finis.
A +
***
Frédéric BROUARD - SQLpro - MVP SQL Server
Spécialiste SQL/BD modélisation de données
SQL & SGBDR http://sqlpro.developpez.com/
Expert SQL Server : http://www.sqlspot.com
audits - optimisation - tuning - formation
On 9 oct, 13:04, Leon <L...@discussions.microsoft.com> wrote:
merci pour la réponse.
Quelle serait les raisons qui font que l'insert via script SQL ne passe p as
par la vue et le même insert dans une procédure stockée déclenche la maj de
l'index de la vue ?
Est ce qu'il peut s'agir d'un bug ou d'une option mal positionnée ?
"bruno reiter" a écrit :
> C'est le comportement normal, une MaJ des tables sous-jacentes provoque la
> MaJ de la vue.
> BR
> "Leon" <L...@discussions.microsoft.com> wrote in message
>news:3CC6B9FF-1060-4891-B9D9-B41F0BC53037@microsoft.com...
> > bonjour,
> > pb constaté sur édition développeur sp2 cu6.
> > après création d'une vue indexé (complexité moyenne).
> > Les actions d'insert dans une table faisant partie de la vue indexé ,
> > entraine lorsque cette action est effectué dans un procédure stoc kée, la
> > lecture compléte de la vue indexé, bien que celle ci ne soit pas appelé
> > lors
> > de l'insert. Le plan d'éxécution montre bien l'insert unitaire et le
> > parcours
> > complet de la vue indexé.
> > Si l'action insert est effectué sur la même table à partir d'un script SQL
> > via management studio le plan d'éxécution ne prend pas en compte la dite
> > vue
> > indexé.
> > Est ce que le comportement dans la procédure stockée est normal ?
> > ps: la requête d'insertion est de la plus simple expression
> > INSERT laTAble (col1, col2) values(1,'valeur');
Il y a des chances que ce soit l'absence de spécification du schéma SQL dans votre INSERT qui en soit la cause.
En effet en l'absence de précision du schéma SQL, le compilateur ne sait quelle table ou vue il doit invoquer et recherche celle-ci dans les différents schéma. Ce qui provoque la recompilation et peut générer des plans d'exécution a moitié finis.
A +
***
Frédéric BROUARD - SQLpro - MVP SQL Server Spécialiste SQL/BD modélisation de données SQL & SGBDR http://sqlpro.developpez.com/ Expert SQL Server : http://www.sqlspot.com audits - optimisation - tuning - formation
On 9 oct, 13:04, Leon wrote:
merci pour la réponse. Quelle serait les raisons qui font que l'insert via script SQL ne passe p as par la vue et le même insert dans une procédure stockée déclenche la maj de l'index de la vue ? Est ce qu'il peut s'agir d'un bug ou d'une option mal positionnée ?
"bruno reiter" a écrit :
> C'est le comportement normal, une MaJ des tables sous-jacentes provoque la > MaJ de la vue.
> BR
> "Leon" wrote in message >news: > > bonjour,
> > pb constaté sur édition développeur sp2 cu6. > > après création d'une vue indexé (complexité moyenne). > > Les actions d'insert dans une table faisant partie de la vue indexé , > > entraine lorsque cette action est effectué dans un procédure stoc kée, la > > lecture compléte de la vue indexé, bien que celle ci ne soit pas appelé > > lors > > de l'insert. Le plan d'éxécution montre bien l'insert unitaire et le > > parcours > > complet de la vue indexé.
> > Si l'action insert est effectué sur la même table à partir d'un script SQL > > via management studio le plan d'éxécution ne prend pas en compte la dite > > vue > > indexé.
> > Est ce que le comportement dans la procédure stockée est normal ?
> > ps: la requête d'insertion est de la plus simple expression > > INSERT laTAble (col1, col2) values(1,'valeur');
bruno reiter
en lançant le script ci-dessous avec le plan d'exec dans SSMS, on voit bien la MaJ de la vue indexée
use adventureworks go update [Production].[Product] set name = 'Adjustable Race1' where productid = 1
BR
"Leon" wrote in message news:
merci pour la réponse. Quelle serait les raisons qui font que l'insert via script SQL ne passe pas par la vue et le même insert dans une procédure stockée déclenche la maj de l'index de la vue ? Est ce qu'il peut s'agir d'un bug ou d'une option mal positionnée ?
"bruno reiter" a écrit :
C'est le comportement normal, une MaJ des tables sous-jacentes provoque la MaJ de la vue.
BR
"Leon" wrote in message news: > bonjour, > > pb constaté sur édition développeur sp2 cu6. > après création d'une vue indexé (complexité moyenne). > Les actions d'insert dans une table faisant partie de la vue indexé, > entraine lorsque cette action est effectué dans un procédure stockée, > la > lecture compléte de la vue indexé, bien que celle ci ne soit pas appelé > lors > de l'insert. Le plan d'éxécution montre bien l'insert unitaire et le > parcours > complet de la vue indexé. > > Si l'action insert est effectué sur la même table à partir d'un script > SQL > via management studio le plan d'éxécution ne prend pas en compte la > dite > vue > indexé. > > Est ce que le comportement dans la procédure stockée est normal ? > > > ps: la requête d'insertion est de la plus simple expression > INSERT laTAble (col1, col2) values(1,'valeur'); >
en lançant le script ci-dessous avec le plan d'exec dans SSMS, on voit bien
la MaJ de la vue indexée
use adventureworks
go
update [Production].[Product]
set name = 'Adjustable Race1'
where productid = 1
BR
"Leon" <Leon@discussions.microsoft.com> wrote in message
news:F8EFB321-9860-4D8C-8FD4-9A591D6FD9C4@microsoft.com...
merci pour la réponse.
Quelle serait les raisons qui font que l'insert via script SQL ne passe
pas
par la vue et le même insert dans une procédure stockée déclenche la maj
de
l'index de la vue ?
Est ce qu'il peut s'agir d'un bug ou d'une option mal positionnée ?
"bruno reiter" a écrit :
C'est le comportement normal, une MaJ des tables sous-jacentes provoque
la
MaJ de la vue.
BR
"Leon" <Leon@discussions.microsoft.com> wrote in message
news:3CC6B9FF-1060-4891-B9D9-B41F0BC53037@microsoft.com...
> bonjour,
>
> pb constaté sur édition développeur sp2 cu6.
> après création d'une vue indexé (complexité moyenne).
> Les actions d'insert dans une table faisant partie de la vue indexé,
> entraine lorsque cette action est effectué dans un procédure stockée,
> la
> lecture compléte de la vue indexé, bien que celle ci ne soit pas appelé
> lors
> de l'insert. Le plan d'éxécution montre bien l'insert unitaire et le
> parcours
> complet de la vue indexé.
>
> Si l'action insert est effectué sur la même table à partir d'un script
> SQL
> via management studio le plan d'éxécution ne prend pas en compte la
> dite
> vue
> indexé.
>
> Est ce que le comportement dans la procédure stockée est normal ?
>
>
> ps: la requête d'insertion est de la plus simple expression
> INSERT laTAble (col1, col2) values(1,'valeur');
>
en lançant le script ci-dessous avec le plan d'exec dans SSMS, on voit bien la MaJ de la vue indexée
use adventureworks go update [Production].[Product] set name = 'Adjustable Race1' where productid = 1
BR
"Leon" wrote in message news:
merci pour la réponse. Quelle serait les raisons qui font que l'insert via script SQL ne passe pas par la vue et le même insert dans une procédure stockée déclenche la maj de l'index de la vue ? Est ce qu'il peut s'agir d'un bug ou d'une option mal positionnée ?
"bruno reiter" a écrit :
C'est le comportement normal, une MaJ des tables sous-jacentes provoque la MaJ de la vue.
BR
"Leon" wrote in message news: > bonjour, > > pb constaté sur édition développeur sp2 cu6. > après création d'une vue indexé (complexité moyenne). > Les actions d'insert dans une table faisant partie de la vue indexé, > entraine lorsque cette action est effectué dans un procédure stockée, > la > lecture compléte de la vue indexé, bien que celle ci ne soit pas appelé > lors > de l'insert. Le plan d'éxécution montre bien l'insert unitaire et le > parcours > complet de la vue indexé. > > Si l'action insert est effectué sur la même table à partir d'un script > SQL > via management studio le plan d'éxécution ne prend pas en compte la > dite > vue > indexé. > > Est ce que le comportement dans la procédure stockée est normal ? > > > ps: la requête d'insertion est de la plus simple expression > INSERT laTAble (col1, col2) values(1,'valeur'); >
Leon
c'est une bonne piste, effectivement lors de mes tests (script SQL) je ne mentionné pas le schéma, alors que celui était bien précisé dans la procédure. merci fred. et désolé pour le dérangement.
"SQLpro" a écrit :
Il y a des chances que ce soit l'absence de spécification du schéma SQL dans votre INSERT qui en soit la cause.
En effet en l'absence de précision du schéma SQL, le compilateur ne sait quelle table ou vue il doit invoquer et recherche celle-ci dans les différents schéma. Ce qui provoque la recompilation et peut générer des plans d'exécution a moitié finis.
A +
***
Frédéric BROUARD - SQLpro - MVP SQL Server Spécialiste SQL/BD modélisation de données SQL & SGBDR http://sqlpro.developpez.com/ Expert SQL Server : http://www.sqlspot.com audits - optimisation - tuning - formation
On 9 oct, 13:04, Leon wrote: > merci pour la réponse. > Quelle serait les raisons qui font que l'insert via script SQL ne passe pas > par la vue et le même insert dans une procédure stockée déclenche la maj de > l'index de la vue ? > Est ce qu'il peut s'agir d'un bug ou d'une option mal positionnée ? > > "bruno reiter" a écrit : > > > C'est le comportement normal, une MaJ des tables sous-jacentes provoque la > > MaJ de la vue. > > > BR > > > "Leon" wrote in message > >news: > > > bonjour, > > > > pb constaté sur édition développeur sp2 cu6. > > > après création d'une vue indexé (complexité moyenne). > > > Les actions d'insert dans une table faisant partie de la vue indexé, > > > entraine lorsque cette action est effectué dans un procédure stockée, la > > > lecture compléte de la vue indexé, bien que celle ci ne soit pas appelé > > > lors > > > de l'insert. Le plan d'éxécution montre bien l'insert unitaire et le > > > parcours > > > complet de la vue indexé. > > > > Si l'action insert est effectué sur la même table à partir d'un script SQL > > > via management studio le plan d'éxécution ne prend pas en compte la dite > > > vue > > > indexé. > > > > Est ce que le comportement dans la procédure stockée est normal ? > > > > ps: la requête d'insertion est de la plus simple expression > > > INSERT laTAble (col1, col2) values(1,'valeur');
c'est une bonne piste, effectivement lors de mes tests (script SQL) je ne
mentionné pas le schéma, alors que celui était bien précisé dans la
procédure.
merci fred. et désolé pour le dérangement.
"SQLpro" a écrit :
Il y a des chances que ce soit l'absence de spécification du schéma
SQL dans votre INSERT qui en soit la cause.
En effet en l'absence de précision du schéma SQL, le compilateur ne
sait quelle table ou vue il doit invoquer et recherche celle-ci dans
les différents schéma. Ce qui provoque la recompilation et peut
générer des plans d'exécution a moitié finis.
A +
***
Frédéric BROUARD - SQLpro - MVP SQL Server
Spécialiste SQL/BD modélisation de données
SQL & SGBDR http://sqlpro.developpez.com/
Expert SQL Server : http://www.sqlspot.com
audits - optimisation - tuning - formation
On 9 oct, 13:04, Leon <L...@discussions.microsoft.com> wrote:
> merci pour la réponse.
> Quelle serait les raisons qui font que l'insert via script SQL ne passe pas
> par la vue et le même insert dans une procédure stockée déclenche la maj de
> l'index de la vue ?
> Est ce qu'il peut s'agir d'un bug ou d'une option mal positionnée ?
>
> "bruno reiter" a écrit :
>
> > C'est le comportement normal, une MaJ des tables sous-jacentes provoque la
> > MaJ de la vue.
>
> > BR
>
> > "Leon" <L...@discussions.microsoft.com> wrote in message
> >news:3CC6B9FF-1060-4891-B9D9-B41F0BC53037@microsoft.com...
> > > bonjour,
>
> > > pb constaté sur édition développeur sp2 cu6.
> > > après création d'une vue indexé (complexité moyenne).
> > > Les actions d'insert dans une table faisant partie de la vue indexé,
> > > entraine lorsque cette action est effectué dans un procédure stockée, la
> > > lecture compléte de la vue indexé, bien que celle ci ne soit pas appelé
> > > lors
> > > de l'insert. Le plan d'éxécution montre bien l'insert unitaire et le
> > > parcours
> > > complet de la vue indexé.
>
> > > Si l'action insert est effectué sur la même table à partir d'un script SQL
> > > via management studio le plan d'éxécution ne prend pas en compte la dite
> > > vue
> > > indexé.
>
> > > Est ce que le comportement dans la procédure stockée est normal ?
>
> > > ps: la requête d'insertion est de la plus simple expression
> > > INSERT laTAble (col1, col2) values(1,'valeur');
c'est une bonne piste, effectivement lors de mes tests (script SQL) je ne mentionné pas le schéma, alors que celui était bien précisé dans la procédure. merci fred. et désolé pour le dérangement.
"SQLpro" a écrit :
Il y a des chances que ce soit l'absence de spécification du schéma SQL dans votre INSERT qui en soit la cause.
En effet en l'absence de précision du schéma SQL, le compilateur ne sait quelle table ou vue il doit invoquer et recherche celle-ci dans les différents schéma. Ce qui provoque la recompilation et peut générer des plans d'exécution a moitié finis.
A +
***
Frédéric BROUARD - SQLpro - MVP SQL Server Spécialiste SQL/BD modélisation de données SQL & SGBDR http://sqlpro.developpez.com/ Expert SQL Server : http://www.sqlspot.com audits - optimisation - tuning - formation
On 9 oct, 13:04, Leon wrote: > merci pour la réponse. > Quelle serait les raisons qui font que l'insert via script SQL ne passe pas > par la vue et le même insert dans une procédure stockée déclenche la maj de > l'index de la vue ? > Est ce qu'il peut s'agir d'un bug ou d'une option mal positionnée ? > > "bruno reiter" a écrit : > > > C'est le comportement normal, une MaJ des tables sous-jacentes provoque la > > MaJ de la vue. > > > BR > > > "Leon" wrote in message > >news: > > > bonjour, > > > > pb constaté sur édition développeur sp2 cu6. > > > après création d'une vue indexé (complexité moyenne). > > > Les actions d'insert dans une table faisant partie de la vue indexé, > > > entraine lorsque cette action est effectué dans un procédure stockée, la > > > lecture compléte de la vue indexé, bien que celle ci ne soit pas appelé > > > lors > > > de l'insert. Le plan d'éxécution montre bien l'insert unitaire et le > > > parcours > > > complet de la vue indexé. > > > > Si l'action insert est effectué sur la même table à partir d'un script SQL > > > via management studio le plan d'éxécution ne prend pas en compte la dite > > > vue > > > indexé. > > > > Est ce que le comportement dans la procédure stockée est normal ? > > > > ps: la requête d'insertion est de la plus simple expression > > > INSERT laTAble (col1, col2) values(1,'valeur');
Leon
merci pour l'info. Mais comme je le précisais dans le message d'origine, en passant par le script le plan d'éxécution ne montre aucune action de mise à jour sur la vue. Comme le signale SQL Pro je ne précisais pas le schéma de la table dans le script SQL, cela peu peut être expliquer la raison de cette différence entre ps et script SQL.
"bruno reiter" a écrit :
en lançant le script ci-dessous avec le plan d'exec dans SSMS, on voit bien la MaJ de la vue indexée
use adventureworks go update [Production].[Product] set name = 'Adjustable Race1' where productid = 1
BR
"Leon" wrote in message news: > merci pour la réponse. > Quelle serait les raisons qui font que l'insert via script SQL ne passe > pas > par la vue et le même insert dans une procédure stockée déclenche la maj > de > l'index de la vue ? > Est ce qu'il peut s'agir d'un bug ou d'une option mal positionnée ? > > "bruno reiter" a écrit : > >> C'est le comportement normal, une MaJ des tables sous-jacentes provoque >> la >> MaJ de la vue. >> >> BR >> >> "Leon" wrote in message >> news: >> > bonjour, >> > >> > pb constaté sur édition développeur sp2 cu6. >> > après création d'une vue indexé (complexité moyenne). >> > Les actions d'insert dans une table faisant partie de la vue indexé, >> > entraine lorsque cette action est effectué dans un procédure stockée, >> > la >> > lecture compléte de la vue indexé, bien que celle ci ne soit pas appelé >> > lors >> > de l'insert. Le plan d'éxécution montre bien l'insert unitaire et le >> > parcours >> > complet de la vue indexé. >> > >> > Si l'action insert est effectué sur la même table à partir d'un script >> > SQL >> > via management studio le plan d'éxécution ne prend pas en compte la >> > dite >> > vue >> > indexé. >> > >> > Est ce que le comportement dans la procédure stockée est normal ? >> > >> > >> > ps: la requête d'insertion est de la plus simple expression >> > INSERT laTAble (col1, col2) values(1,'valeur'); >> > >> >>
merci pour l'info.
Mais comme je le précisais dans le message d'origine, en passant par le
script le plan d'éxécution ne montre aucune action de mise à jour sur la vue.
Comme le signale SQL Pro je ne précisais pas le schéma de la table dans le
script SQL, cela peu peut être expliquer la raison de cette différence entre
ps et script SQL.
"bruno reiter" a écrit :
en lançant le script ci-dessous avec le plan d'exec dans SSMS, on voit bien
la MaJ de la vue indexée
use adventureworks
go
update [Production].[Product]
set name = 'Adjustable Race1'
where productid = 1
BR
"Leon" <Leon@discussions.microsoft.com> wrote in message
news:F8EFB321-9860-4D8C-8FD4-9A591D6FD9C4@microsoft.com...
> merci pour la réponse.
> Quelle serait les raisons qui font que l'insert via script SQL ne passe
> pas
> par la vue et le même insert dans une procédure stockée déclenche la maj
> de
> l'index de la vue ?
> Est ce qu'il peut s'agir d'un bug ou d'une option mal positionnée ?
>
> "bruno reiter" a écrit :
>
>> C'est le comportement normal, une MaJ des tables sous-jacentes provoque
>> la
>> MaJ de la vue.
>>
>> BR
>>
>> "Leon" <Leon@discussions.microsoft.com> wrote in message
>> news:3CC6B9FF-1060-4891-B9D9-B41F0BC53037@microsoft.com...
>> > bonjour,
>> >
>> > pb constaté sur édition développeur sp2 cu6.
>> > après création d'une vue indexé (complexité moyenne).
>> > Les actions d'insert dans une table faisant partie de la vue indexé,
>> > entraine lorsque cette action est effectué dans un procédure stockée,
>> > la
>> > lecture compléte de la vue indexé, bien que celle ci ne soit pas appelé
>> > lors
>> > de l'insert. Le plan d'éxécution montre bien l'insert unitaire et le
>> > parcours
>> > complet de la vue indexé.
>> >
>> > Si l'action insert est effectué sur la même table à partir d'un script
>> > SQL
>> > via management studio le plan d'éxécution ne prend pas en compte la
>> > dite
>> > vue
>> > indexé.
>> >
>> > Est ce que le comportement dans la procédure stockée est normal ?
>> >
>> >
>> > ps: la requête d'insertion est de la plus simple expression
>> > INSERT laTAble (col1, col2) values(1,'valeur');
>> >
>>
>>
merci pour l'info. Mais comme je le précisais dans le message d'origine, en passant par le script le plan d'éxécution ne montre aucune action de mise à jour sur la vue. Comme le signale SQL Pro je ne précisais pas le schéma de la table dans le script SQL, cela peu peut être expliquer la raison de cette différence entre ps et script SQL.
"bruno reiter" a écrit :
en lançant le script ci-dessous avec le plan d'exec dans SSMS, on voit bien la MaJ de la vue indexée
use adventureworks go update [Production].[Product] set name = 'Adjustable Race1' where productid = 1
BR
"Leon" wrote in message news: > merci pour la réponse. > Quelle serait les raisons qui font que l'insert via script SQL ne passe > pas > par la vue et le même insert dans une procédure stockée déclenche la maj > de > l'index de la vue ? > Est ce qu'il peut s'agir d'un bug ou d'une option mal positionnée ? > > "bruno reiter" a écrit : > >> C'est le comportement normal, une MaJ des tables sous-jacentes provoque >> la >> MaJ de la vue. >> >> BR >> >> "Leon" wrote in message >> news: >> > bonjour, >> > >> > pb constaté sur édition développeur sp2 cu6. >> > après création d'une vue indexé (complexité moyenne). >> > Les actions d'insert dans une table faisant partie de la vue indexé, >> > entraine lorsque cette action est effectué dans un procédure stockée, >> > la >> > lecture compléte de la vue indexé, bien que celle ci ne soit pas appelé >> > lors >> > de l'insert. Le plan d'éxécution montre bien l'insert unitaire et le >> > parcours >> > complet de la vue indexé. >> > >> > Si l'action insert est effectué sur la même table à partir d'un script >> > SQL >> > via management studio le plan d'éxécution ne prend pas en compte la >> > dite >> > vue >> > indexé. >> > >> > Est ce que le comportement dans la procédure stockée est normal ? >> > >> > >> > ps: la requête d'insertion est de la plus simple expression >> > INSERT laTAble (col1, col2) values(1,'valeur'); >> > >> >>
