Ok j'ai trouvé, mais le problème c'est que ma SP utilise des table
temporaire, chose qu'on ne peut pas faire dans une vue ou une fonction...
Alors que faire...?
"bruno reiter" a écrit :select ... from UDF_xxx where ...
br
"ILyasse" a écrit dans le message de
news:Mais alors comment appellé cette fonction dans la vue.
SELECT my_function from quoi ?... C'est ce que je ne comprend pas très
bien
...
"bruno reiter" a écrit :non, la fonction ne pourra pas appeler la SP, mais la fonction peut faire
exactement ce que fait la SP
br
"ILyasse" a écrit dans le message de
news:Ce n'est pas si absurde qu'on le croit. Normalement je n'ai pas besoid
d'une
view. J'exécute la SP et j'ai les résultat. Le problème est que cette
SP
sera
appellé par un Rapport Crystal , jusqu'ici ça va. Mais le hic c'est que
le
rapport crystal utilisera des paramètre. Et il semble que Crystal
Report
lorsqu'il utilise paramètre, génére une requête SQL du genre SELECT....
where
parameter.... . Malheureusement un Select sur une SP ne fonctionne.
J'obtiens
donc un message d'erreur dans crystal disant 'Failes to open Rowset'.
Alors
que la SP fonctionne bien. DOnc je me suis dis je vais créer une view
et
cette view fera appelle a cette SP. Et un rapport crystal qui utilise
un
paramètre fonctionne très bien sur une view...
Une solution pourrait être d'utiliser une fonction, mais alors cette
fonction sera en fait la stored procedure. Mais la stored procedure
renvoie
plusieurs colonne, est-ce que cela ne causerai pas un problème.
Exemple:
CREATE My_StoredPRoc as Select * from authors....
Create function My_Function as exec My_StoredProc...
Comment appellé cette fonction dans la vue ?
CREATE VIEW My_view...
Select My_Function from QUOI ? (from authors ?)
"SQLpro [MVP]" a écrit :ILyasse a écrit :Bonjour,
J'amerai savoir si elle est possible de faire appelle à une stored
procedure
a partir d'nue view.
J'utilise Sql server 2000. Sachant que la stored procedure rempli
une
table
et à la fin fait un select de cette table. Je voudrai faire une view
qui me
renvoie le résultat de ce select.
Merci d'avance pour votre aide.
C'est totalement absurde :
Une SP peut encapsuler de nombreuses requêtes et gérer de multiples
transactions.
Or une requête EST une transaction.
On ne peut donc appeler une SP dans une requête pour la bonne et
simple
raison qu'il ne peut y avoir un fractionnement de transactions à
l'intérieur d'un SELECT par exemple !!! Cela permettrait de rendre la
transaction SELECT non atomique ... ce qui est parfaitement absurde.
En revanche une fonction ne peut pas contenir une transaction. Elle
peut
donc (et c'est son rôle) être appelée dans un ordre SQL quelconque
(SELECT, INSERT, UPDATE, DELETE...)
De plus une SP qui execute un SELECT final peut être vu comme une
requête SELECT. DOnc, ne changez rien à votre code. Ouvrez simplement
le
curseur côté client pour voir les données qui sont renvoyées par la
SP.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage
SQL
Le site sur le langage SQL et les SGBDR :
http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning,
optimisation
********************* http://www.datasapiens.com
***********************
Ok j'ai trouvé, mais le problème c'est que ma SP utilise des table
temporaire, chose qu'on ne peut pas faire dans une vue ou une fonction...
Alors que faire...?
"bruno reiter" a écrit :
select ... from UDF_xxx where ...
br
"ILyasse" <ILyasse@discussions.microsoft.com> a écrit dans le message de
news: 9924A723-67D3-438B-BFD1-565F9ADE3727@microsoft.com...
Mais alors comment appellé cette fonction dans la vue.
SELECT my_function from quoi ?... C'est ce que je ne comprend pas très
bien
...
"bruno reiter" a écrit :
non, la fonction ne pourra pas appeler la SP, mais la fonction peut faire
exactement ce que fait la SP
br
"ILyasse" <ILyasse@discussions.microsoft.com> a écrit dans le message de
news: DBAAE2EC-611A-4D51-A2B0-B5633F0E6267@microsoft.com...
Ce n'est pas si absurde qu'on le croit. Normalement je n'ai pas besoid
d'une
view. J'exécute la SP et j'ai les résultat. Le problème est que cette
SP
sera
appellé par un Rapport Crystal , jusqu'ici ça va. Mais le hic c'est que
le
rapport crystal utilisera des paramètre. Et il semble que Crystal
Report
lorsqu'il utilise paramètre, génére une requête SQL du genre SELECT....
where
parameter.... . Malheureusement un Select sur une SP ne fonctionne.
J'obtiens
donc un message d'erreur dans crystal disant 'Failes to open Rowset'.
Alors
que la SP fonctionne bien. DOnc je me suis dis je vais créer une view
et
cette view fera appelle a cette SP. Et un rapport crystal qui utilise
un
paramètre fonctionne très bien sur une view...
Une solution pourrait être d'utiliser une fonction, mais alors cette
fonction sera en fait la stored procedure. Mais la stored procedure
renvoie
plusieurs colonne, est-ce que cela ne causerai pas un problème.
Exemple:
CREATE My_StoredPRoc as Select * from authors....
Create function My_Function as exec My_StoredProc...
Comment appellé cette fonction dans la vue ?
CREATE VIEW My_view...
Select My_Function from QUOI ? (from authors ?)
"SQLpro [MVP]" a écrit :
ILyasse a écrit :
Bonjour,
J'amerai savoir si elle est possible de faire appelle à une stored
procedure
a partir d'nue view.
J'utilise Sql server 2000. Sachant que la stored procedure rempli
une
table
et à la fin fait un select de cette table. Je voudrai faire une view
qui me
renvoie le résultat de ce select.
Merci d'avance pour votre aide.
C'est totalement absurde :
Une SP peut encapsuler de nombreuses requêtes et gérer de multiples
transactions.
Or une requête EST une transaction.
On ne peut donc appeler une SP dans une requête pour la bonne et
simple
raison qu'il ne peut y avoir un fractionnement de transactions à
l'intérieur d'un SELECT par exemple !!! Cela permettrait de rendre la
transaction SELECT non atomique ... ce qui est parfaitement absurde.
En revanche une fonction ne peut pas contenir une transaction. Elle
peut
donc (et c'est son rôle) être appelée dans un ordre SQL quelconque
(SELECT, INSERT, UPDATE, DELETE...)
De plus une SP qui execute un SELECT final peut être vu comme une
requête SELECT. DOnc, ne changez rien à votre code. Ouvrez simplement
le
curseur côté client pour voir les données qui sont renvoyées par la
SP.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage
SQL
Le site sur le langage SQL et les SGBDR :
http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning,
optimisation
********************* http://www.datasapiens.com
***********************
Ok j'ai trouvé, mais le problème c'est que ma SP utilise des table
temporaire, chose qu'on ne peut pas faire dans une vue ou une fonction...
Alors que faire...?
"bruno reiter" a écrit :select ... from UDF_xxx where ...
br
"ILyasse" a écrit dans le message de
news:Mais alors comment appellé cette fonction dans la vue.
SELECT my_function from quoi ?... C'est ce que je ne comprend pas très
bien
...
"bruno reiter" a écrit :non, la fonction ne pourra pas appeler la SP, mais la fonction peut faire
exactement ce que fait la SP
br
"ILyasse" a écrit dans le message de
news:Ce n'est pas si absurde qu'on le croit. Normalement je n'ai pas besoid
d'une
view. J'exécute la SP et j'ai les résultat. Le problème est que cette
SP
sera
appellé par un Rapport Crystal , jusqu'ici ça va. Mais le hic c'est que
le
rapport crystal utilisera des paramètre. Et il semble que Crystal
Report
lorsqu'il utilise paramètre, génére une requête SQL du genre SELECT....
where
parameter.... . Malheureusement un Select sur une SP ne fonctionne.
J'obtiens
donc un message d'erreur dans crystal disant 'Failes to open Rowset'.
Alors
que la SP fonctionne bien. DOnc je me suis dis je vais créer une view
et
cette view fera appelle a cette SP. Et un rapport crystal qui utilise
un
paramètre fonctionne très bien sur une view...
Une solution pourrait être d'utiliser une fonction, mais alors cette
fonction sera en fait la stored procedure. Mais la stored procedure
renvoie
plusieurs colonne, est-ce que cela ne causerai pas un problème.
Exemple:
CREATE My_StoredPRoc as Select * from authors....
Create function My_Function as exec My_StoredProc...
Comment appellé cette fonction dans la vue ?
CREATE VIEW My_view...
Select My_Function from QUOI ? (from authors ?)
"SQLpro [MVP]" a écrit :ILyasse a écrit :Bonjour,
J'amerai savoir si elle est possible de faire appelle à une stored
procedure
a partir d'nue view.
J'utilise Sql server 2000. Sachant que la stored procedure rempli
une
table
et à la fin fait un select de cette table. Je voudrai faire une view
qui me
renvoie le résultat de ce select.
Merci d'avance pour votre aide.
C'est totalement absurde :
Une SP peut encapsuler de nombreuses requêtes et gérer de multiples
transactions.
Or une requête EST une transaction.
On ne peut donc appeler une SP dans une requête pour la bonne et
simple
raison qu'il ne peut y avoir un fractionnement de transactions à
l'intérieur d'un SELECT par exemple !!! Cela permettrait de rendre la
transaction SELECT non atomique ... ce qui est parfaitement absurde.
En revanche une fonction ne peut pas contenir une transaction. Elle
peut
donc (et c'est son rôle) être appelée dans un ordre SQL quelconque
(SELECT, INSERT, UPDATE, DELETE...)
De plus une SP qui execute un SELECT final peut être vu comme une
requête SELECT. DOnc, ne changez rien à votre code. Ouvrez simplement
le
curseur côté client pour voir les données qui sont renvoyées par la
SP.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage
SQL
Le site sur le langage SQL et les SGBDR :
http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning,
optimisation
********************* http://www.datasapiens.com
***********************
erreur Bruno... Grave erreur !
Une requête même SELECT est une transaction....
En effet il faut garantir la lisibilité consistante de la table :
Que se passe t-il si lors de mon SELECT :
1) l'utilisateur A modifie le prix des article de la catégorie skdcsbklc
2) l'utilisateur B supprime une colonne
???
La norme SQL va même nettement plus loin en distinguant le STATEMENT SQL
et la requête SQL.
Est un STATEMENT toute requête SELECT qui ne contient :
pas de table dérivée, pas d'opération ensembliste, pas de CTE.
Et le STATEMENT est une transaction. En revanche la QUERY qui contiendrait
une table dérivée, une op ensembliste ou un CTE ne l'est pas et les
données peuvent changer entre l'exécution d'une des partie de la query.
Sur cet aspect de la norme, SQL Server le respecte à la lettre, tant est
si bien que si tu veut par exmple assurer la consistence d'une requête
comme celle-ci :
SELECT *
FROM (SELECT *
FROM INFORMATION_SCHEMA.COLUMNS) T
UNION ALL
SELECT *
FROM INFORMATION_SCHEMA.COLUMNS
Il te faut la placer dans une transaction
Si tu n'est pas convaincu, cherche les post de Steve Kass, Drew
University, MVP, à ce sujet !
Nous avons été très étonné que tout ceci fasse explicitement partie de la
norme, car nous croyons tous qu'une requête SELECT était atomique (donc
une transaction)...
A +
bruno reiter a écrit :peut-etre est-ce la journée polémique? ;-)
Je ne pense pas qu'on puisse dire
une requête EST une transaction
Je suis certain que tu sais ce qu'est une transaction, mais qq1 qui n'est
pas sûr et lit cela peut etre induit en erreur.
Il y a transaction implicitement s'il y a
modification(INSERT,UPDATE,DELETE), ou si explicitement on donne un ordre
BEGIN TRAN
br
"SQLpro [MVP]" a écrit dans le message de
news:ILyasse a écrit :Bonjour,
J'amerai savoir si elle est possible de faire appelle à une stored
procedure a partir d'nue view.
J'utilise Sql server 2000. Sachant que la stored procedure rempli une
table et à la fin fait un select de cette table. Je voudrai faire une
view qui me renvoie le résultat de ce select. Merci d'avance pour votre
aide.
C'est totalement absurde :
Une SP peut encapsuler de nombreuses requêtes et gérer de multiples
transactions.
Or une requête EST une transaction.
On ne peut donc appeler une SP dans une requête pour la bonne et simple
raison qu'il ne peut y avoir un fractionnement de transactions à
l'intérieur d'un SELECT par exemple !!! Cela permettrait de rendre la
transaction SELECT non atomique ... ce qui est parfaitement absurde.
En revanche une fonction ne peut pas contenir une transaction. Elle peut
donc (et c'est son rôle) être appelée dans un ordre SQL quelconque
(SELECT, INSERT, UPDATE, DELETE...)
De plus une SP qui execute un SELECT final peut être vu comme une
requête SELECT. DOnc, ne changez rien à votre code. Ouvrez simplement le
curseur côté client pour voir les données qui sont renvoyées par la SP.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
erreur Bruno... Grave erreur !
Une requête même SELECT est une transaction....
En effet il faut garantir la lisibilité consistante de la table :
Que se passe t-il si lors de mon SELECT :
1) l'utilisateur A modifie le prix des article de la catégorie skdcsbklc
2) l'utilisateur B supprime une colonne
???
La norme SQL va même nettement plus loin en distinguant le STATEMENT SQL
et la requête SQL.
Est un STATEMENT toute requête SELECT qui ne contient :
pas de table dérivée, pas d'opération ensembliste, pas de CTE.
Et le STATEMENT est une transaction. En revanche la QUERY qui contiendrait
une table dérivée, une op ensembliste ou un CTE ne l'est pas et les
données peuvent changer entre l'exécution d'une des partie de la query.
Sur cet aspect de la norme, SQL Server le respecte à la lettre, tant est
si bien que si tu veut par exmple assurer la consistence d'une requête
comme celle-ci :
SELECT *
FROM (SELECT *
FROM INFORMATION_SCHEMA.COLUMNS) T
UNION ALL
SELECT *
FROM INFORMATION_SCHEMA.COLUMNS
Il te faut la placer dans une transaction
Si tu n'est pas convaincu, cherche les post de Steve Kass, Drew
University, MVP, à ce sujet !
Nous avons été très étonné que tout ceci fasse explicitement partie de la
norme, car nous croyons tous qu'une requête SELECT était atomique (donc
une transaction)...
A +
bruno reiter a écrit :
peut-etre est-ce la journée polémique? ;-)
Je ne pense pas qu'on puisse dire
une requête EST une transaction
Je suis certain que tu sais ce qu'est une transaction, mais qq1 qui n'est
pas sûr et lit cela peut etre induit en erreur.
Il y a transaction implicitement s'il y a
modification(INSERT,UPDATE,DELETE), ou si explicitement on donne un ordre
BEGIN TRAN
br
"SQLpro [MVP]" <brouardf@club-internet.fr> a écrit dans le message de
news: O7ojsqHOGHA.1288@TK2MSFTNGP09.phx.gbl...
ILyasse a écrit :
Bonjour,
J'amerai savoir si elle est possible de faire appelle à une stored
procedure a partir d'nue view.
J'utilise Sql server 2000. Sachant que la stored procedure rempli une
table et à la fin fait un select de cette table. Je voudrai faire une
view qui me renvoie le résultat de ce select. Merci d'avance pour votre
aide.
C'est totalement absurde :
Une SP peut encapsuler de nombreuses requêtes et gérer de multiples
transactions.
Or une requête EST une transaction.
On ne peut donc appeler une SP dans une requête pour la bonne et simple
raison qu'il ne peut y avoir un fractionnement de transactions à
l'intérieur d'un SELECT par exemple !!! Cela permettrait de rendre la
transaction SELECT non atomique ... ce qui est parfaitement absurde.
En revanche une fonction ne peut pas contenir une transaction. Elle peut
donc (et c'est son rôle) être appelée dans un ordre SQL quelconque
(SELECT, INSERT, UPDATE, DELETE...)
De plus une SP qui execute un SELECT final peut être vu comme une
requête SELECT. DOnc, ne changez rien à votre code. Ouvrez simplement le
curseur côté client pour voir les données qui sont renvoyées par la SP.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
erreur Bruno... Grave erreur !
Une requête même SELECT est une transaction....
En effet il faut garantir la lisibilité consistante de la table :
Que se passe t-il si lors de mon SELECT :
1) l'utilisateur A modifie le prix des article de la catégorie skdcsbklc
2) l'utilisateur B supprime une colonne
???
La norme SQL va même nettement plus loin en distinguant le STATEMENT SQL
et la requête SQL.
Est un STATEMENT toute requête SELECT qui ne contient :
pas de table dérivée, pas d'opération ensembliste, pas de CTE.
Et le STATEMENT est une transaction. En revanche la QUERY qui contiendrait
une table dérivée, une op ensembliste ou un CTE ne l'est pas et les
données peuvent changer entre l'exécution d'une des partie de la query.
Sur cet aspect de la norme, SQL Server le respecte à la lettre, tant est
si bien que si tu veut par exmple assurer la consistence d'une requête
comme celle-ci :
SELECT *
FROM (SELECT *
FROM INFORMATION_SCHEMA.COLUMNS) T
UNION ALL
SELECT *
FROM INFORMATION_SCHEMA.COLUMNS
Il te faut la placer dans une transaction
Si tu n'est pas convaincu, cherche les post de Steve Kass, Drew
University, MVP, à ce sujet !
Nous avons été très étonné que tout ceci fasse explicitement partie de la
norme, car nous croyons tous qu'une requête SELECT était atomique (donc
une transaction)...
A +
bruno reiter a écrit :peut-etre est-ce la journée polémique? ;-)
Je ne pense pas qu'on puisse dire
une requête EST une transaction
Je suis certain que tu sais ce qu'est une transaction, mais qq1 qui n'est
pas sûr et lit cela peut etre induit en erreur.
Il y a transaction implicitement s'il y a
modification(INSERT,UPDATE,DELETE), ou si explicitement on donne un ordre
BEGIN TRAN
br
"SQLpro [MVP]" a écrit dans le message de
news:ILyasse a écrit :Bonjour,
J'amerai savoir si elle est possible de faire appelle à une stored
procedure a partir d'nue view.
J'utilise Sql server 2000. Sachant que la stored procedure rempli une
table et à la fin fait un select de cette table. Je voudrai faire une
view qui me renvoie le résultat de ce select. Merci d'avance pour votre
aide.
C'est totalement absurde :
Une SP peut encapsuler de nombreuses requêtes et gérer de multiples
transactions.
Or une requête EST une transaction.
On ne peut donc appeler une SP dans une requête pour la bonne et simple
raison qu'il ne peut y avoir un fractionnement de transactions à
l'intérieur d'un SELECT par exemple !!! Cela permettrait de rendre la
transaction SELECT non atomique ... ce qui est parfaitement absurde.
En revanche une fonction ne peut pas contenir une transaction. Elle peut
donc (et c'est son rôle) être appelée dans un ordre SQL quelconque
(SELECT, INSERT, UPDATE, DELETE...)
De plus une SP qui execute un SELECT final peut être vu comme une
requête SELECT. DOnc, ne changez rien à votre code. Ouvrez simplement le
curseur côté client pour voir les données qui sont renvoyées par la SP.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
ILyasse a écrit :
> Ok j'ai trouvé, mais le problème c'est que ma SP utilise des table
> temporaire, chose qu'on ne peut pas faire dans une vue ou une fonction...
> Alors que faire...?
mais si !!!!
Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/sqlserver/transactsql/#L3.2
Après vous pouvez faire par exemple :
SELECT *
FROM dbo.MaFonction(...)
A +
>
> "bruno reiter" a écrit :
>
>> select ... from UDF_xxx where ...
>>
>> br
>>
>>
>> "ILyasse" a écrit dans le message de
>> news:
>>> Mais alors comment appellé cette fonction dans la vue.
>>> SELECT my_function from quoi ?... C'est ce que je ne comprend pas très
>>> bien
>>> ...
>>>
>>> "bruno reiter" a écrit :
>>>
>>>> non, la fonction ne pourra pas appeler la SP, mais la fonction peut faire
>>>> exactement ce que fait la SP
>>>>
>>>> br
>>>>
>>>> "ILyasse" a écrit dans le message de
>>>> news:
>>>>> Ce n'est pas si absurde qu'on le croit. Normalement je n'ai pas besoid
>>>>> d'une
>>>>> view. J'exécute la SP et j'ai les résultat. Le problème est que cette
>>>>> SP
>>>>> sera
>>>>> appellé par un Rapport Crystal , jusqu'ici ça va. Mais le hic c'est que
>>>>> le
>>>>> rapport crystal utilisera des paramètre. Et il semble que Crystal
>>>>> Report
>>>>> lorsqu'il utilise paramètre, génére une requête SQL du genre SELECT....
>>>>> where
>>>>> parameter.... . Malheureusement un Select sur une SP ne fonctionne.
>>>>> J'obtiens
>>>>> donc un message d'erreur dans crystal disant 'Failes to open Rowset'.
>>>>> Alors
>>>>> que la SP fonctionne bien. DOnc je me suis dis je vais créer une view
>>>>> et
>>>>> cette view fera appelle a cette SP. Et un rapport crystal qui utilise
>>>>> un
>>>>> paramètre fonctionne très bien sur une view...
>>>>>
>>>>> Une solution pourrait être d'utiliser une fonction, mais alors cette
>>>>> fonction sera en fait la stored procedure. Mais la stored procedure
>>>>> renvoie
>>>>> plusieurs colonne, est-ce que cela ne causerai pas un problème.
>>>>>
>>>>> Exemple:
>>>>> CREATE My_StoredPRoc as Select * from authors....
>>>>>
>>>>> Create function My_Function as exec My_StoredProc...
>>>>>
>>>>> Comment appellé cette fonction dans la vue ?
>>>>>
>>>>> CREATE VIEW My_view...
>>>>>
>>>>> Select My_Function from QUOI ? (from authors ?)
>>>>>
>>>>>
>>>>> "SQLpro [MVP]" a écrit :
>>>>>
>>>>>> ILyasse a écrit :
>>>>>>> Bonjour,
>>>>>>>
>>>>>>> J'amerai savoir si elle est possible de faire appelle à une stored
>>>>>>> procedure
>>>>>>> a partir d'nue view.
>>>>>>> J'utilise Sql server 2000. Sachant que la stored procedure rempli
>>>>>>> une
>>>>>>> table
>>>>>>> et à la fin fait un select de cette table. Je voudrai faire une view
>>>>>>> qui me
>>>>>>> renvoie le résultat de ce select.
>>>>>>>
>>>>>>> Merci d'avance pour votre aide.
>>>>>>>
>>>>>>>
>>>>>> C'est totalement absurde :
>>>>>>
>>>>>> Une SP peut encapsuler de nombreuses requêtes et gérer de multiples
>>>>>> transactions.
>>>>>> Or une requête EST une transaction.
>>>>>> On ne peut donc appeler une SP dans une requête pour la bonne et
>>>>>> simple
>>>>>> raison qu'il ne peut y avoir un fractionnement de transactions à
>>>>>> l'intérieur d'un SELECT par exemple !!! Cela permettrait de rendre la
>>>>>> transaction SELECT non atomique ... ce qui est parfaitement absurde.
>>>>>>
>>>>>> En revanche une fonction ne peut pas contenir une transaction. Elle
>>>>>> peut
>>>>>> donc (et c'est son rôle) être appelée dans un ordre SQL quelconque
>>>>>> (SELECT, INSERT, UPDATE, DELETE...)
>>>>>>
>>>>>>
>>>>>> De plus une SP qui execute un SELECT final peut être vu comme une
>>>>>> requête SELECT. DOnc, ne changez rien à votre code. Ouvrez simplement
>>>>>> le
>>>>>> curseur côté client pour voir les données qui sont renvoyées par la
>>>>>> SP.
>>>>>>
>>>>>> A +
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage
>>>>>> SQL
>>>>>> Le site sur le langage SQL et les SGBDR :
>>>>>> http://sqlpro.developpez.com
>>>>>> Audit, conseil, expertise, formation, modélisation, tuning,
>>>>>> optimisation
>>>>>> ********************* http://www.datasapiens.com
>>>>>> ***********************
>>>>>>
>>>>
>>>>
>>
>>
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
ILyasse a écrit :
> Ok j'ai trouvé, mais le problème c'est que ma SP utilise des table
> temporaire, chose qu'on ne peut pas faire dans une vue ou une fonction...
> Alors que faire...?
mais si !!!!
Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/sqlserver/transactsql/#L3.2
Après vous pouvez faire par exemple :
SELECT *
FROM dbo.MaFonction(...)
A +
>
> "bruno reiter" a écrit :
>
>> select ... from UDF_xxx where ...
>>
>> br
>>
>>
>> "ILyasse" <ILyasse@discussions.microsoft.com> a écrit dans le message de
>> news: 9924A723-67D3-438B-BFD1-565F9ADE3727@microsoft.com...
>>> Mais alors comment appellé cette fonction dans la vue.
>>> SELECT my_function from quoi ?... C'est ce que je ne comprend pas très
>>> bien
>>> ...
>>>
>>> "bruno reiter" a écrit :
>>>
>>>> non, la fonction ne pourra pas appeler la SP, mais la fonction peut faire
>>>> exactement ce que fait la SP
>>>>
>>>> br
>>>>
>>>> "ILyasse" <ILyasse@discussions.microsoft.com> a écrit dans le message de
>>>> news: DBAAE2EC-611A-4D51-A2B0-B5633F0E6267@microsoft.com...
>>>>> Ce n'est pas si absurde qu'on le croit. Normalement je n'ai pas besoid
>>>>> d'une
>>>>> view. J'exécute la SP et j'ai les résultat. Le problème est que cette
>>>>> SP
>>>>> sera
>>>>> appellé par un Rapport Crystal , jusqu'ici ça va. Mais le hic c'est que
>>>>> le
>>>>> rapport crystal utilisera des paramètre. Et il semble que Crystal
>>>>> Report
>>>>> lorsqu'il utilise paramètre, génére une requête SQL du genre SELECT....
>>>>> where
>>>>> parameter.... . Malheureusement un Select sur une SP ne fonctionne.
>>>>> J'obtiens
>>>>> donc un message d'erreur dans crystal disant 'Failes to open Rowset'.
>>>>> Alors
>>>>> que la SP fonctionne bien. DOnc je me suis dis je vais créer une view
>>>>> et
>>>>> cette view fera appelle a cette SP. Et un rapport crystal qui utilise
>>>>> un
>>>>> paramètre fonctionne très bien sur une view...
>>>>>
>>>>> Une solution pourrait être d'utiliser une fonction, mais alors cette
>>>>> fonction sera en fait la stored procedure. Mais la stored procedure
>>>>> renvoie
>>>>> plusieurs colonne, est-ce que cela ne causerai pas un problème.
>>>>>
>>>>> Exemple:
>>>>> CREATE My_StoredPRoc as Select * from authors....
>>>>>
>>>>> Create function My_Function as exec My_StoredProc...
>>>>>
>>>>> Comment appellé cette fonction dans la vue ?
>>>>>
>>>>> CREATE VIEW My_view...
>>>>>
>>>>> Select My_Function from QUOI ? (from authors ?)
>>>>>
>>>>>
>>>>> "SQLpro [MVP]" a écrit :
>>>>>
>>>>>> ILyasse a écrit :
>>>>>>> Bonjour,
>>>>>>>
>>>>>>> J'amerai savoir si elle est possible de faire appelle à une stored
>>>>>>> procedure
>>>>>>> a partir d'nue view.
>>>>>>> J'utilise Sql server 2000. Sachant que la stored procedure rempli
>>>>>>> une
>>>>>>> table
>>>>>>> et à la fin fait un select de cette table. Je voudrai faire une view
>>>>>>> qui me
>>>>>>> renvoie le résultat de ce select.
>>>>>>>
>>>>>>> Merci d'avance pour votre aide.
>>>>>>>
>>>>>>>
>>>>>> C'est totalement absurde :
>>>>>>
>>>>>> Une SP peut encapsuler de nombreuses requêtes et gérer de multiples
>>>>>> transactions.
>>>>>> Or une requête EST une transaction.
>>>>>> On ne peut donc appeler une SP dans une requête pour la bonne et
>>>>>> simple
>>>>>> raison qu'il ne peut y avoir un fractionnement de transactions à
>>>>>> l'intérieur d'un SELECT par exemple !!! Cela permettrait de rendre la
>>>>>> transaction SELECT non atomique ... ce qui est parfaitement absurde.
>>>>>>
>>>>>> En revanche une fonction ne peut pas contenir une transaction. Elle
>>>>>> peut
>>>>>> donc (et c'est son rôle) être appelée dans un ordre SQL quelconque
>>>>>> (SELECT, INSERT, UPDATE, DELETE...)
>>>>>>
>>>>>>
>>>>>> De plus une SP qui execute un SELECT final peut être vu comme une
>>>>>> requête SELECT. DOnc, ne changez rien à votre code. Ouvrez simplement
>>>>>> le
>>>>>> curseur côté client pour voir les données qui sont renvoyées par la
>>>>>> SP.
>>>>>>
>>>>>> A +
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage
>>>>>> SQL
>>>>>> Le site sur le langage SQL et les SGBDR :
>>>>>> http://sqlpro.developpez.com
>>>>>> Audit, conseil, expertise, formation, modélisation, tuning,
>>>>>> optimisation
>>>>>> ********************* http://www.datasapiens.com
>>>>>> ***********************
>>>>>>
>>>>
>>>>
>>
>>
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
ILyasse a écrit :
> Ok j'ai trouvé, mais le problème c'est que ma SP utilise des table
> temporaire, chose qu'on ne peut pas faire dans une vue ou une fonction...
> Alors que faire...?
mais si !!!!
Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/sqlserver/transactsql/#L3.2
Après vous pouvez faire par exemple :
SELECT *
FROM dbo.MaFonction(...)
A +
>
> "bruno reiter" a écrit :
>
>> select ... from UDF_xxx where ...
>>
>> br
>>
>>
>> "ILyasse" a écrit dans le message de
>> news:
>>> Mais alors comment appellé cette fonction dans la vue.
>>> SELECT my_function from quoi ?... C'est ce que je ne comprend pas très
>>> bien
>>> ...
>>>
>>> "bruno reiter" a écrit :
>>>
>>>> non, la fonction ne pourra pas appeler la SP, mais la fonction peut faire
>>>> exactement ce que fait la SP
>>>>
>>>> br
>>>>
>>>> "ILyasse" a écrit dans le message de
>>>> news:
>>>>> Ce n'est pas si absurde qu'on le croit. Normalement je n'ai pas besoid
>>>>> d'une
>>>>> view. J'exécute la SP et j'ai les résultat. Le problème est que cette
>>>>> SP
>>>>> sera
>>>>> appellé par un Rapport Crystal , jusqu'ici ça va. Mais le hic c'est que
>>>>> le
>>>>> rapport crystal utilisera des paramètre. Et il semble que Crystal
>>>>> Report
>>>>> lorsqu'il utilise paramètre, génére une requête SQL du genre SELECT....
>>>>> where
>>>>> parameter.... . Malheureusement un Select sur une SP ne fonctionne.
>>>>> J'obtiens
>>>>> donc un message d'erreur dans crystal disant 'Failes to open Rowset'.
>>>>> Alors
>>>>> que la SP fonctionne bien. DOnc je me suis dis je vais créer une view
>>>>> et
>>>>> cette view fera appelle a cette SP. Et un rapport crystal qui utilise
>>>>> un
>>>>> paramètre fonctionne très bien sur une view...
>>>>>
>>>>> Une solution pourrait être d'utiliser une fonction, mais alors cette
>>>>> fonction sera en fait la stored procedure. Mais la stored procedure
>>>>> renvoie
>>>>> plusieurs colonne, est-ce que cela ne causerai pas un problème.
>>>>>
>>>>> Exemple:
>>>>> CREATE My_StoredPRoc as Select * from authors....
>>>>>
>>>>> Create function My_Function as exec My_StoredProc...
>>>>>
>>>>> Comment appellé cette fonction dans la vue ?
>>>>>
>>>>> CREATE VIEW My_view...
>>>>>
>>>>> Select My_Function from QUOI ? (from authors ?)
>>>>>
>>>>>
>>>>> "SQLpro [MVP]" a écrit :
>>>>>
>>>>>> ILyasse a écrit :
>>>>>>> Bonjour,
>>>>>>>
>>>>>>> J'amerai savoir si elle est possible de faire appelle à une stored
>>>>>>> procedure
>>>>>>> a partir d'nue view.
>>>>>>> J'utilise Sql server 2000. Sachant que la stored procedure rempli
>>>>>>> une
>>>>>>> table
>>>>>>> et à la fin fait un select de cette table. Je voudrai faire une view
>>>>>>> qui me
>>>>>>> renvoie le résultat de ce select.
>>>>>>>
>>>>>>> Merci d'avance pour votre aide.
>>>>>>>
>>>>>>>
>>>>>> C'est totalement absurde :
>>>>>>
>>>>>> Une SP peut encapsuler de nombreuses requêtes et gérer de multiples
>>>>>> transactions.
>>>>>> Or une requête EST une transaction.
>>>>>> On ne peut donc appeler une SP dans une requête pour la bonne et
>>>>>> simple
>>>>>> raison qu'il ne peut y avoir un fractionnement de transactions à
>>>>>> l'intérieur d'un SELECT par exemple !!! Cela permettrait de rendre la
>>>>>> transaction SELECT non atomique ... ce qui est parfaitement absurde.
>>>>>>
>>>>>> En revanche une fonction ne peut pas contenir une transaction. Elle
>>>>>> peut
>>>>>> donc (et c'est son rôle) être appelée dans un ordre SQL quelconque
>>>>>> (SELECT, INSERT, UPDATE, DELETE...)
>>>>>>
>>>>>>
>>>>>> De plus une SP qui execute un SELECT final peut être vu comme une
>>>>>> requête SELECT. DOnc, ne changez rien à votre code. Ouvrez simplement
>>>>>> le
>>>>>> curseur côté client pour voir les données qui sont renvoyées par la
>>>>>> SP.
>>>>>>
>>>>>> A +
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage
>>>>>> SQL
>>>>>> Le site sur le langage SQL et les SGBDR :
>>>>>> http://sqlpro.developpez.com
>>>>>> Audit, conseil, expertise, formation, modélisation, tuning,
>>>>>> optimisation
>>>>>> ********************* http://www.datasapiens.com
>>>>>> ***********************
>>>>>>
>>>>
>>>>
>>
>>
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Merci pour votre article mais malheureusement cela ne résoud pas mon problème.
J'avais plusieurs table temporaire dans ma SP qui sont utiliser lors de la
manipulation des données.
fais un select de cette table. Les fonctions ne permettent pas d'utiliser des
tables temporaire, donc je ne peux pas les utiliser. De plus dans mon select
il y a un ORDER by donc je ne pourrais même pas l'utiliser dans ma vue....
Alors que faire ...?
"SQLpro [MVP]" a écrit :ILyasse a écrit :Ok j'ai trouvé, mais le problème c'est que ma SP utilise des table
temporaire, chose qu'on ne peut pas faire dans une vue ou une fonction...
Alors que faire...?
mais si !!!!
Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/sqlserver/transactsql/#L3.2
Après vous pouvez faire par exemple :
SELECT *
FROM dbo.MaFonction(...)
A +"bruno reiter" a écrit :select ... from UDF_xxx where ...
br
"ILyasse" a écrit dans le message de
news:Mais alors comment appellé cette fonction dans la vue.
SELECT my_function from quoi ?... C'est ce que je ne comprend pas très
bien
...
"bruno reiter" a écrit :non, la fonction ne pourra pas appeler la SP, mais la fonction peut faire
exactement ce que fait la SP
br
"ILyasse" a écrit dans le message de
news:Ce n'est pas si absurde qu'on le croit. Normalement je n'ai pas besoid
d'une
view. J'exécute la SP et j'ai les résultat. Le problème est que cette
SP
sera
appellé par un Rapport Crystal , jusqu'ici ça va. Mais le hic c'est que
le
rapport crystal utilisera des paramètre. Et il semble que Crystal
Report
lorsqu'il utilise paramètre, génére une requête SQL du genre SELECT....
where
parameter.... . Malheureusement un Select sur une SP ne fonctionne.
J'obtiens
donc un message d'erreur dans crystal disant 'Failes to open Rowset'.
Alors
que la SP fonctionne bien. DOnc je me suis dis je vais créer une view
et
cette view fera appelle a cette SP. Et un rapport crystal qui utilise
un
paramètre fonctionne très bien sur une view...
Une solution pourrait être d'utiliser une fonction, mais alors cette
fonction sera en fait la stored procedure. Mais la stored procedure
renvoie
plusieurs colonne, est-ce que cela ne causerai pas un problème.
Exemple:
CREATE My_StoredPRoc as Select * from authors....
Create function My_Function as exec My_StoredProc...
Comment appellé cette fonction dans la vue ?
CREATE VIEW My_view...
Select My_Function from QUOI ? (from authors ?)
"SQLpro [MVP]" a écrit :ILyasse a écrit :Bonjour,
J'amerai savoir si elle est possible de faire appelle à une stored
procedure
a partir d'nue view.
J'utilise Sql server 2000. Sachant que la stored procedure rempli
une
table
et à la fin fait un select de cette table. Je voudrai faire une view
qui me
renvoie le résultat de ce select.
Merci d'avance pour votre aide.
C'est totalement absurde :
Une SP peut encapsuler de nombreuses requêtes et gérer de multiples
transactions.
Or une requête EST une transaction.
On ne peut donc appeler une SP dans une requête pour la bonne et
simple
raison qu'il ne peut y avoir un fractionnement de transactions à
l'intérieur d'un SELECT par exemple !!! Cela permettrait de rendre la
transaction SELECT non atomique ... ce qui est parfaitement absurde.
En revanche une fonction ne peut pas contenir une transaction. Elle
peut
donc (et c'est son rôle) être appelée dans un ordre SQL quelconque
(SELECT, INSERT, UPDATE, DELETE...)
De plus une SP qui execute un SELECT final peut être vu comme une
requête SELECT. DOnc, ne changez rien à votre code. Ouvrez simplement
le
curseur côté client pour voir les données qui sont renvoyées par la
SP.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage
SQL
Le site sur le langage SQL et les SGBDR :
http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning,
optimisation
********************* http://www.datasapiens.com
***********************
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Merci pour votre article mais malheureusement cela ne résoud pas mon problème.
J'avais plusieurs table temporaire dans ma SP qui sont utiliser lors de la
manipulation des données.
fais un select de cette table. Les fonctions ne permettent pas d'utiliser des
tables temporaire, donc je ne peux pas les utiliser. De plus dans mon select
il y a un ORDER by donc je ne pourrais même pas l'utiliser dans ma vue....
Alors que faire ...?
"SQLpro [MVP]" a écrit :
ILyasse a écrit :
Ok j'ai trouvé, mais le problème c'est que ma SP utilise des table
temporaire, chose qu'on ne peut pas faire dans une vue ou une fonction...
Alors que faire...?
mais si !!!!
Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/sqlserver/transactsql/#L3.2
Après vous pouvez faire par exemple :
SELECT *
FROM dbo.MaFonction(...)
A +
"bruno reiter" a écrit :
select ... from UDF_xxx where ...
br
"ILyasse" <ILyasse@discussions.microsoft.com> a écrit dans le message de
news: 9924A723-67D3-438B-BFD1-565F9ADE3727@microsoft.com...
Mais alors comment appellé cette fonction dans la vue.
SELECT my_function from quoi ?... C'est ce que je ne comprend pas très
bien
...
"bruno reiter" a écrit :
non, la fonction ne pourra pas appeler la SP, mais la fonction peut faire
exactement ce que fait la SP
br
"ILyasse" <ILyasse@discussions.microsoft.com> a écrit dans le message de
news: DBAAE2EC-611A-4D51-A2B0-B5633F0E6267@microsoft.com...
Ce n'est pas si absurde qu'on le croit. Normalement je n'ai pas besoid
d'une
view. J'exécute la SP et j'ai les résultat. Le problème est que cette
SP
sera
appellé par un Rapport Crystal , jusqu'ici ça va. Mais le hic c'est que
le
rapport crystal utilisera des paramètre. Et il semble que Crystal
Report
lorsqu'il utilise paramètre, génére une requête SQL du genre SELECT....
where
parameter.... . Malheureusement un Select sur une SP ne fonctionne.
J'obtiens
donc un message d'erreur dans crystal disant 'Failes to open Rowset'.
Alors
que la SP fonctionne bien. DOnc je me suis dis je vais créer une view
et
cette view fera appelle a cette SP. Et un rapport crystal qui utilise
un
paramètre fonctionne très bien sur une view...
Une solution pourrait être d'utiliser une fonction, mais alors cette
fonction sera en fait la stored procedure. Mais la stored procedure
renvoie
plusieurs colonne, est-ce que cela ne causerai pas un problème.
Exemple:
CREATE My_StoredPRoc as Select * from authors....
Create function My_Function as exec My_StoredProc...
Comment appellé cette fonction dans la vue ?
CREATE VIEW My_view...
Select My_Function from QUOI ? (from authors ?)
"SQLpro [MVP]" a écrit :
ILyasse a écrit :
Bonjour,
J'amerai savoir si elle est possible de faire appelle à une stored
procedure
a partir d'nue view.
J'utilise Sql server 2000. Sachant que la stored procedure rempli
une
table
et à la fin fait un select de cette table. Je voudrai faire une view
qui me
renvoie le résultat de ce select.
Merci d'avance pour votre aide.
C'est totalement absurde :
Une SP peut encapsuler de nombreuses requêtes et gérer de multiples
transactions.
Or une requête EST une transaction.
On ne peut donc appeler une SP dans une requête pour la bonne et
simple
raison qu'il ne peut y avoir un fractionnement de transactions à
l'intérieur d'un SELECT par exemple !!! Cela permettrait de rendre la
transaction SELECT non atomique ... ce qui est parfaitement absurde.
En revanche une fonction ne peut pas contenir une transaction. Elle
peut
donc (et c'est son rôle) être appelée dans un ordre SQL quelconque
(SELECT, INSERT, UPDATE, DELETE...)
De plus une SP qui execute un SELECT final peut être vu comme une
requête SELECT. DOnc, ne changez rien à votre code. Ouvrez simplement
le
curseur côté client pour voir les données qui sont renvoyées par la
SP.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage
SQL
Le site sur le langage SQL et les SGBDR :
http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning,
optimisation
********************* http://www.datasapiens.com
***********************
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Merci pour votre article mais malheureusement cela ne résoud pas mon problème.
J'avais plusieurs table temporaire dans ma SP qui sont utiliser lors de la
manipulation des données.
fais un select de cette table. Les fonctions ne permettent pas d'utiliser des
tables temporaire, donc je ne peux pas les utiliser. De plus dans mon select
il y a un ORDER by donc je ne pourrais même pas l'utiliser dans ma vue....
Alors que faire ...?
"SQLpro [MVP]" a écrit :ILyasse a écrit :Ok j'ai trouvé, mais le problème c'est que ma SP utilise des table
temporaire, chose qu'on ne peut pas faire dans une vue ou une fonction...
Alors que faire...?
mais si !!!!
Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/sqlserver/transactsql/#L3.2
Après vous pouvez faire par exemple :
SELECT *
FROM dbo.MaFonction(...)
A +"bruno reiter" a écrit :select ... from UDF_xxx where ...
br
"ILyasse" a écrit dans le message de
news:Mais alors comment appellé cette fonction dans la vue.
SELECT my_function from quoi ?... C'est ce que je ne comprend pas très
bien
...
"bruno reiter" a écrit :non, la fonction ne pourra pas appeler la SP, mais la fonction peut faire
exactement ce que fait la SP
br
"ILyasse" a écrit dans le message de
news:Ce n'est pas si absurde qu'on le croit. Normalement je n'ai pas besoid
d'une
view. J'exécute la SP et j'ai les résultat. Le problème est que cette
SP
sera
appellé par un Rapport Crystal , jusqu'ici ça va. Mais le hic c'est que
le
rapport crystal utilisera des paramètre. Et il semble que Crystal
Report
lorsqu'il utilise paramètre, génére une requête SQL du genre SELECT....
where
parameter.... . Malheureusement un Select sur une SP ne fonctionne.
J'obtiens
donc un message d'erreur dans crystal disant 'Failes to open Rowset'.
Alors
que la SP fonctionne bien. DOnc je me suis dis je vais créer une view
et
cette view fera appelle a cette SP. Et un rapport crystal qui utilise
un
paramètre fonctionne très bien sur une view...
Une solution pourrait être d'utiliser une fonction, mais alors cette
fonction sera en fait la stored procedure. Mais la stored procedure
renvoie
plusieurs colonne, est-ce que cela ne causerai pas un problème.
Exemple:
CREATE My_StoredPRoc as Select * from authors....
Create function My_Function as exec My_StoredProc...
Comment appellé cette fonction dans la vue ?
CREATE VIEW My_view...
Select My_Function from QUOI ? (from authors ?)
"SQLpro [MVP]" a écrit :ILyasse a écrit :Bonjour,
J'amerai savoir si elle est possible de faire appelle à une stored
procedure
a partir d'nue view.
J'utilise Sql server 2000. Sachant que la stored procedure rempli
une
table
et à la fin fait un select de cette table. Je voudrai faire une view
qui me
renvoie le résultat de ce select.
Merci d'avance pour votre aide.
C'est totalement absurde :
Une SP peut encapsuler de nombreuses requêtes et gérer de multiples
transactions.
Or une requête EST une transaction.
On ne peut donc appeler une SP dans une requête pour la bonne et
simple
raison qu'il ne peut y avoir un fractionnement de transactions à
l'intérieur d'un SELECT par exemple !!! Cela permettrait de rendre la
transaction SELECT non atomique ... ce qui est parfaitement absurde.
En revanche une fonction ne peut pas contenir une transaction. Elle
peut
donc (et c'est son rôle) être appelée dans un ordre SQL quelconque
(SELECT, INSERT, UPDATE, DELETE...)
De plus une SP qui execute un SELECT final peut être vu comme une
requête SELECT. DOnc, ne changez rien à votre code. Ouvrez simplement
le
curseur côté client pour voir les données qui sont renvoyées par la
SP.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage
SQL
Le site sur le langage SQL et les SGBDR :
http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning,
optimisation
********************* http://www.datasapiens.com
***********************
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Je ne sais pas si c'est une grave erreur, mais ce dont tu parles est un
problème d'isolation et pour gérer les problèmes de modification de
structure pendant un select, il y a un lock sur le schema.
à ma connaissance, il y a transaction quand il y a modification de données
(toutes les définitions que je connais le disent),
et une transaction, par
définition, est ACID, donc Isolée. Pendant le select il est tout a fait
possible de modifier les données accédées, soit après avoir laché le shared
lock (donc encore pendant le select), soit en faisant du dirty read. Donc
pour moi il n'y pas isolation et donc pas transaction.
br
"SQLpro [MVP]" a écrit dans le message de news:
%erreur Bruno... Grave erreur !
Une requête même SELECT est une transaction....
En effet il faut garantir la lisibilité consistante de la table :
Que se passe t-il si lors de mon SELECT :
1) l'utilisateur A modifie le prix des article de la catégorie skdcsbklc
2) l'utilisateur B supprime une colonne
???
La norme SQL va même nettement plus loin en distinguant le STATEMENT SQL
et la requête SQL.
Est un STATEMENT toute requête SELECT qui ne contient :
pas de table dérivée, pas d'opération ensembliste, pas de CTE.
Et le STATEMENT est une transaction. En revanche la QUERY qui contiendrait
une table dérivée, une op ensembliste ou un CTE ne l'est pas et les
données peuvent changer entre l'exécution d'une des partie de la query.
Sur cet aspect de la norme, SQL Server le respecte à la lettre, tant est
si bien que si tu veut par exmple assurer la consistence d'une requête
comme celle-ci :
SELECT *
FROM (SELECT *
FROM INFORMATION_SCHEMA.COLUMNS) T
UNION ALL
SELECT *
FROM INFORMATION_SCHEMA.COLUMNS
Il te faut la placer dans une transaction
Si tu n'est pas convaincu, cherche les post de Steve Kass, Drew
University, MVP, à ce sujet !
Nous avons été très étonné que tout ceci fasse explicitement partie de la
norme, car nous croyons tous qu'une requête SELECT était atomique (donc
une transaction)...
A +
bruno reiter a écrit :peut-etre est-ce la journée polémique? ;-)
Je ne pense pas qu'on puisse dire
une requête EST une transaction
Je suis certain que tu sais ce qu'est une transaction, mais qq1 qui n'est
pas sûr et lit cela peut etre induit en erreur.
Il y a transaction implicitement s'il y a
modification(INSERT,UPDATE,DELETE), ou si explicitement on donne un ordre
BEGIN TRAN
br
"SQLpro [MVP]" a écrit dans le message de
news:ILyasse a écrit :Bonjour,
J'amerai savoir si elle est possible de faire appelle à une stored
procedure a partir d'nue view.
J'utilise Sql server 2000. Sachant que la stored procedure rempli une
table et à la fin fait un select de cette table. Je voudrai faire une
view qui me renvoie le résultat de ce select. Merci d'avance pour votre
aide.
C'est totalement absurde :
Une SP peut encapsuler de nombreuses requêtes et gérer de multiples
transactions.
Or une requête EST une transaction.
On ne peut donc appeler une SP dans une requête pour la bonne et simple
raison qu'il ne peut y avoir un fractionnement de transactions à
l'intérieur d'un SELECT par exemple !!! Cela permettrait de rendre la
transaction SELECT non atomique ... ce qui est parfaitement absurde.
En revanche une fonction ne peut pas contenir une transaction. Elle peut
donc (et c'est son rôle) être appelée dans un ordre SQL quelconque
(SELECT, INSERT, UPDATE, DELETE...)
De plus une SP qui execute un SELECT final peut être vu comme une
requête SELECT. DOnc, ne changez rien à votre code. Ouvrez simplement le
curseur côté client pour voir les données qui sont renvoyées par la SP.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Je ne sais pas si c'est une grave erreur, mais ce dont tu parles est un
problème d'isolation et pour gérer les problèmes de modification de
structure pendant un select, il y a un lock sur le schema.
à ma connaissance, il y a transaction quand il y a modification de données
(toutes les définitions que je connais le disent),
et une transaction, par
définition, est ACID, donc Isolée. Pendant le select il est tout a fait
possible de modifier les données accédées, soit après avoir laché le shared
lock (donc encore pendant le select), soit en faisant du dirty read. Donc
pour moi il n'y pas isolation et donc pas transaction.
br
"SQLpro [MVP]" <brouardf@club-internet.fr> a écrit dans le message de news:
%23KncpNIOGHA.2992@tk2msftngp13.phx.gbl...
erreur Bruno... Grave erreur !
Une requête même SELECT est une transaction....
En effet il faut garantir la lisibilité consistante de la table :
Que se passe t-il si lors de mon SELECT :
1) l'utilisateur A modifie le prix des article de la catégorie skdcsbklc
2) l'utilisateur B supprime une colonne
???
La norme SQL va même nettement plus loin en distinguant le STATEMENT SQL
et la requête SQL.
Est un STATEMENT toute requête SELECT qui ne contient :
pas de table dérivée, pas d'opération ensembliste, pas de CTE.
Et le STATEMENT est une transaction. En revanche la QUERY qui contiendrait
une table dérivée, une op ensembliste ou un CTE ne l'est pas et les
données peuvent changer entre l'exécution d'une des partie de la query.
Sur cet aspect de la norme, SQL Server le respecte à la lettre, tant est
si bien que si tu veut par exmple assurer la consistence d'une requête
comme celle-ci :
SELECT *
FROM (SELECT *
FROM INFORMATION_SCHEMA.COLUMNS) T
UNION ALL
SELECT *
FROM INFORMATION_SCHEMA.COLUMNS
Il te faut la placer dans une transaction
Si tu n'est pas convaincu, cherche les post de Steve Kass, Drew
University, MVP, à ce sujet !
Nous avons été très étonné que tout ceci fasse explicitement partie de la
norme, car nous croyons tous qu'une requête SELECT était atomique (donc
une transaction)...
A +
bruno reiter a écrit :
peut-etre est-ce la journée polémique? ;-)
Je ne pense pas qu'on puisse dire
une requête EST une transaction
Je suis certain que tu sais ce qu'est une transaction, mais qq1 qui n'est
pas sûr et lit cela peut etre induit en erreur.
Il y a transaction implicitement s'il y a
modification(INSERT,UPDATE,DELETE), ou si explicitement on donne un ordre
BEGIN TRAN
br
"SQLpro [MVP]" <brouardf@club-internet.fr> a écrit dans le message de
news: O7ojsqHOGHA.1288@TK2MSFTNGP09.phx.gbl...
ILyasse a écrit :
Bonjour,
J'amerai savoir si elle est possible de faire appelle à une stored
procedure a partir d'nue view.
J'utilise Sql server 2000. Sachant que la stored procedure rempli une
table et à la fin fait un select de cette table. Je voudrai faire une
view qui me renvoie le résultat de ce select. Merci d'avance pour votre
aide.
C'est totalement absurde :
Une SP peut encapsuler de nombreuses requêtes et gérer de multiples
transactions.
Or une requête EST une transaction.
On ne peut donc appeler une SP dans une requête pour la bonne et simple
raison qu'il ne peut y avoir un fractionnement de transactions à
l'intérieur d'un SELECT par exemple !!! Cela permettrait de rendre la
transaction SELECT non atomique ... ce qui est parfaitement absurde.
En revanche une fonction ne peut pas contenir une transaction. Elle peut
donc (et c'est son rôle) être appelée dans un ordre SQL quelconque
(SELECT, INSERT, UPDATE, DELETE...)
De plus une SP qui execute un SELECT final peut être vu comme une
requête SELECT. DOnc, ne changez rien à votre code. Ouvrez simplement le
curseur côté client pour voir les données qui sont renvoyées par la SP.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Je ne sais pas si c'est une grave erreur, mais ce dont tu parles est un
problème d'isolation et pour gérer les problèmes de modification de
structure pendant un select, il y a un lock sur le schema.
à ma connaissance, il y a transaction quand il y a modification de données
(toutes les définitions que je connais le disent),
et une transaction, par
définition, est ACID, donc Isolée. Pendant le select il est tout a fait
possible de modifier les données accédées, soit après avoir laché le shared
lock (donc encore pendant le select), soit en faisant du dirty read. Donc
pour moi il n'y pas isolation et donc pas transaction.
br
"SQLpro [MVP]" a écrit dans le message de news:
%erreur Bruno... Grave erreur !
Une requête même SELECT est une transaction....
En effet il faut garantir la lisibilité consistante de la table :
Que se passe t-il si lors de mon SELECT :
1) l'utilisateur A modifie le prix des article de la catégorie skdcsbklc
2) l'utilisateur B supprime une colonne
???
La norme SQL va même nettement plus loin en distinguant le STATEMENT SQL
et la requête SQL.
Est un STATEMENT toute requête SELECT qui ne contient :
pas de table dérivée, pas d'opération ensembliste, pas de CTE.
Et le STATEMENT est une transaction. En revanche la QUERY qui contiendrait
une table dérivée, une op ensembliste ou un CTE ne l'est pas et les
données peuvent changer entre l'exécution d'une des partie de la query.
Sur cet aspect de la norme, SQL Server le respecte à la lettre, tant est
si bien que si tu veut par exmple assurer la consistence d'une requête
comme celle-ci :
SELECT *
FROM (SELECT *
FROM INFORMATION_SCHEMA.COLUMNS) T
UNION ALL
SELECT *
FROM INFORMATION_SCHEMA.COLUMNS
Il te faut la placer dans une transaction
Si tu n'est pas convaincu, cherche les post de Steve Kass, Drew
University, MVP, à ce sujet !
Nous avons été très étonné que tout ceci fasse explicitement partie de la
norme, car nous croyons tous qu'une requête SELECT était atomique (donc
une transaction)...
A +
bruno reiter a écrit :peut-etre est-ce la journée polémique? ;-)
Je ne pense pas qu'on puisse dire
une requête EST une transaction
Je suis certain que tu sais ce qu'est une transaction, mais qq1 qui n'est
pas sûr et lit cela peut etre induit en erreur.
Il y a transaction implicitement s'il y a
modification(INSERT,UPDATE,DELETE), ou si explicitement on donne un ordre
BEGIN TRAN
br
"SQLpro [MVP]" a écrit dans le message de
news:ILyasse a écrit :Bonjour,
J'amerai savoir si elle est possible de faire appelle à une stored
procedure a partir d'nue view.
J'utilise Sql server 2000. Sachant que la stored procedure rempli une
table et à la fin fait un select de cette table. Je voudrai faire une
view qui me renvoie le résultat de ce select. Merci d'avance pour votre
aide.
C'est totalement absurde :
Une SP peut encapsuler de nombreuses requêtes et gérer de multiples
transactions.
Or une requête EST une transaction.
On ne peut donc appeler une SP dans une requête pour la bonne et simple
raison qu'il ne peut y avoir un fractionnement de transactions à
l'intérieur d'un SELECT par exemple !!! Cela permettrait de rendre la
transaction SELECT non atomique ... ce qui est parfaitement absurde.
En revanche une fonction ne peut pas contenir une transaction. Elle peut
donc (et c'est son rôle) être appelée dans un ordre SQL quelconque
(SELECT, INSERT, UPDATE, DELETE...)
De plus une SP qui execute un SELECT final peut être vu comme une
requête SELECT. DOnc, ne changez rien à votre code. Ouvrez simplement le
curseur côté client pour voir les données qui sont renvoyées par la SP.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Merci pour votre article mais malheureusement cela ne résoud pas mon
J'avais plusieurs table temporaire dans ma SP qui sont utiliser lors de la
manipulation des données. A la fin j'insère tout dans une vrai table et je
fais un select de cette table. Les fonctions ne permettent pas d'utiliser
tables temporaire, donc je ne peux pas les utiliser. De plus dans mon
il y a un ORDER by donc je ne pourrais même pas l'utiliser dans ma vue....
Alors que faire ...?
"SQLpro [MVP]" a écrit :
> ILyasse a écrit :
> > Ok j'ai trouvé, mais le problème c'est que ma SP utilise des table
> > temporaire, chose qu'on ne peut pas faire dans une vue ou une
> > Alors que faire...?
>
> mais si !!!!
> Lisez l'article que j'ai écrit à ce sujet :
> http://sqlpro.developpez.com/cours/sqlserver/transactsql/#L3.2
>
>
> Après vous pouvez faire par exemple :
>
> SELECT *
> FROM dbo.MaFonction(...)
>
> A +
>
>
> >
> > "bruno reiter" a écrit :
> >
> >> select ... from UDF_xxx where ...
> >>
> >> br
> >>
> >>
> >> "ILyasse" a écrit dans le message
> >> news:
> >>> Mais alors comment appellé cette fonction dans la vue.
> >>> SELECT my_function from quoi ?... C'est ce que je ne comprend pas
> >>> bien
> >>> ...
> >>>
> >>> "bruno reiter" a écrit :
> >>>
> >>>> non, la fonction ne pourra pas appeler la SP, mais la fonction peut
> >>>> exactement ce que fait la SP
> >>>>
> >>>> br
> >>>>
> >>>> "ILyasse" a écrit dans le
> >>>> news:
> >>>>> Ce n'est pas si absurde qu'on le croit. Normalement je n'ai pas
> >>>>> d'une
> >>>>> view. J'exécute la SP et j'ai les résultat. Le problème est que
> >>>>> SP
> >>>>> sera
> >>>>> appellé par un Rapport Crystal , jusqu'ici ça va. Mais le hic
> >>>>> le
> >>>>> rapport crystal utilisera des paramètre. Et il semble que Crystal
> >>>>> Report
> >>>>> lorsqu'il utilise paramètre, génére une requête SQL du genre
> >>>>> where
> >>>>> parameter.... . Malheureusement un Select sur une SP ne
> >>>>> J'obtiens
> >>>>> donc un message d'erreur dans crystal disant 'Failes to open
> >>>>> Alors
> >>>>> que la SP fonctionne bien. DOnc je me suis dis je vais créer une
> >>>>> et
> >>>>> cette view fera appelle a cette SP. Et un rapport crystal qui
> >>>>> un
> >>>>> paramètre fonctionne très bien sur une view...
> >>>>>
> >>>>> Une solution pourrait être d'utiliser une fonction, mais alors
> >>>>> fonction sera en fait la stored procedure. Mais la stored
> >>>>> renvoie
> >>>>> plusieurs colonne, est-ce que cela ne causerai pas un problème.
> >>>>>
> >>>>> Exemple:
> >>>>> CREATE My_StoredPRoc as Select * from authors....
> >>>>>
> >>>>> Create function My_Function as exec My_StoredProc...
> >>>>>
> >>>>> Comment appellé cette fonction dans la vue ?
> >>>>>
> >>>>> CREATE VIEW My_view...
> >>>>>
> >>>>> Select My_Function from QUOI ? (from authors ?)
> >>>>>
> >>>>>
> >>>>> "SQLpro [MVP]" a écrit :
> >>>>>
> >>>>>> ILyasse a écrit :
> >>>>>>> Bonjour,
> >>>>>>>
> >>>>>>> J'amerai savoir si elle est possible de faire appelle à une
> >>>>>>> procedure
> >>>>>>> a partir d'nue view.
> >>>>>>> J'utilise Sql server 2000. Sachant que la stored procedure
> >>>>>>> une
> >>>>>>> table
> >>>>>>> et à la fin fait un select de cette table. Je voudrai faire une
> >>>>>>> qui me
> >>>>>>> renvoie le résultat de ce select.
> >>>>>>>
> >>>>>>> Merci d'avance pour votre aide.
> >>>>>>>
> >>>>>>>
> >>>>>> C'est totalement absurde :
> >>>>>>
> >>>>>> Une SP peut encapsuler de nombreuses requêtes et gérer de
> >>>>>> transactions.
> >>>>>> Or une requête EST une transaction.
> >>>>>> On ne peut donc appeler une SP dans une requête pour la bonne et
> >>>>>> simple
> >>>>>> raison qu'il ne peut y avoir un fractionnement de transactions à
> >>>>>> l'intérieur d'un SELECT par exemple !!! Cela permettrait de
> >>>>>> transaction SELECT non atomique ... ce qui est parfaitement
> >>>>>>
> >>>>>> En revanche une fonction ne peut pas contenir une transaction.
> >>>>>> peut
> >>>>>> donc (et c'est son rôle) être appelée dans un ordre SQL
> >>>>>> (SELECT, INSERT, UPDATE, DELETE...)
> >>>>>>
> >>>>>>
> >>>>>> De plus une SP qui execute un SELECT final peut être vu comme une
> >>>>>> requête SELECT. DOnc, ne changez rien à votre code. Ouvrez
> >>>>>> le
> >>>>>> curseur côté client pour voir les données qui sont renvoyées par
> >>>>>> SP.
> >>>>>>
> >>>>>> A +
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et
> >>>>>> SQL
> >>>>>> Le site sur le langage SQL et les SGBDR :
> >>>>>> http://sqlpro.developpez.com
> >>>>>> Audit, conseil, expertise, formation, modélisation, tuning,
> >>>>>> optimisation
> >>>>>> ********************* http://www.datasapiens.com
> >>>>>> ***********************
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
> --
> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
> ********************* http://www.datasapiens.com ***********************
>
Merci pour votre article mais malheureusement cela ne résoud pas mon
J'avais plusieurs table temporaire dans ma SP qui sont utiliser lors de la
manipulation des données. A la fin j'insère tout dans une vrai table et je
fais un select de cette table. Les fonctions ne permettent pas d'utiliser
tables temporaire, donc je ne peux pas les utiliser. De plus dans mon
il y a un ORDER by donc je ne pourrais même pas l'utiliser dans ma vue....
Alors que faire ...?
"SQLpro [MVP]" a écrit :
> ILyasse a écrit :
> > Ok j'ai trouvé, mais le problème c'est que ma SP utilise des table
> > temporaire, chose qu'on ne peut pas faire dans une vue ou une
> > Alors que faire...?
>
> mais si !!!!
> Lisez l'article que j'ai écrit à ce sujet :
> http://sqlpro.developpez.com/cours/sqlserver/transactsql/#L3.2
>
>
> Après vous pouvez faire par exemple :
>
> SELECT *
> FROM dbo.MaFonction(...)
>
> A +
>
>
> >
> > "bruno reiter" a écrit :
> >
> >> select ... from UDF_xxx where ...
> >>
> >> br
> >>
> >>
> >> "ILyasse" <ILyasse@discussions.microsoft.com> a écrit dans le message
> >> news: 9924A723-67D3-438B-BFD1-565F9ADE3727@microsoft.com...
> >>> Mais alors comment appellé cette fonction dans la vue.
> >>> SELECT my_function from quoi ?... C'est ce que je ne comprend pas
> >>> bien
> >>> ...
> >>>
> >>> "bruno reiter" a écrit :
> >>>
> >>>> non, la fonction ne pourra pas appeler la SP, mais la fonction peut
> >>>> exactement ce que fait la SP
> >>>>
> >>>> br
> >>>>
> >>>> "ILyasse" <ILyasse@discussions.microsoft.com> a écrit dans le
> >>>> news: DBAAE2EC-611A-4D51-A2B0-B5633F0E6267@microsoft.com...
> >>>>> Ce n'est pas si absurde qu'on le croit. Normalement je n'ai pas
> >>>>> d'une
> >>>>> view. J'exécute la SP et j'ai les résultat. Le problème est que
> >>>>> SP
> >>>>> sera
> >>>>> appellé par un Rapport Crystal , jusqu'ici ça va. Mais le hic
> >>>>> le
> >>>>> rapport crystal utilisera des paramètre. Et il semble que Crystal
> >>>>> Report
> >>>>> lorsqu'il utilise paramètre, génére une requête SQL du genre
> >>>>> where
> >>>>> parameter.... . Malheureusement un Select sur une SP ne
> >>>>> J'obtiens
> >>>>> donc un message d'erreur dans crystal disant 'Failes to open
> >>>>> Alors
> >>>>> que la SP fonctionne bien. DOnc je me suis dis je vais créer une
> >>>>> et
> >>>>> cette view fera appelle a cette SP. Et un rapport crystal qui
> >>>>> un
> >>>>> paramètre fonctionne très bien sur une view...
> >>>>>
> >>>>> Une solution pourrait être d'utiliser une fonction, mais alors
> >>>>> fonction sera en fait la stored procedure. Mais la stored
> >>>>> renvoie
> >>>>> plusieurs colonne, est-ce que cela ne causerai pas un problème.
> >>>>>
> >>>>> Exemple:
> >>>>> CREATE My_StoredPRoc as Select * from authors....
> >>>>>
> >>>>> Create function My_Function as exec My_StoredProc...
> >>>>>
> >>>>> Comment appellé cette fonction dans la vue ?
> >>>>>
> >>>>> CREATE VIEW My_view...
> >>>>>
> >>>>> Select My_Function from QUOI ? (from authors ?)
> >>>>>
> >>>>>
> >>>>> "SQLpro [MVP]" a écrit :
> >>>>>
> >>>>>> ILyasse a écrit :
> >>>>>>> Bonjour,
> >>>>>>>
> >>>>>>> J'amerai savoir si elle est possible de faire appelle à une
> >>>>>>> procedure
> >>>>>>> a partir d'nue view.
> >>>>>>> J'utilise Sql server 2000. Sachant que la stored procedure
> >>>>>>> une
> >>>>>>> table
> >>>>>>> et à la fin fait un select de cette table. Je voudrai faire une
> >>>>>>> qui me
> >>>>>>> renvoie le résultat de ce select.
> >>>>>>>
> >>>>>>> Merci d'avance pour votre aide.
> >>>>>>>
> >>>>>>>
> >>>>>> C'est totalement absurde :
> >>>>>>
> >>>>>> Une SP peut encapsuler de nombreuses requêtes et gérer de
> >>>>>> transactions.
> >>>>>> Or une requête EST une transaction.
> >>>>>> On ne peut donc appeler une SP dans une requête pour la bonne et
> >>>>>> simple
> >>>>>> raison qu'il ne peut y avoir un fractionnement de transactions à
> >>>>>> l'intérieur d'un SELECT par exemple !!! Cela permettrait de
> >>>>>> transaction SELECT non atomique ... ce qui est parfaitement
> >>>>>>
> >>>>>> En revanche une fonction ne peut pas contenir une transaction.
> >>>>>> peut
> >>>>>> donc (et c'est son rôle) être appelée dans un ordre SQL
> >>>>>> (SELECT, INSERT, UPDATE, DELETE...)
> >>>>>>
> >>>>>>
> >>>>>> De plus une SP qui execute un SELECT final peut être vu comme une
> >>>>>> requête SELECT. DOnc, ne changez rien à votre code. Ouvrez
> >>>>>> le
> >>>>>> curseur côté client pour voir les données qui sont renvoyées par
> >>>>>> SP.
> >>>>>>
> >>>>>> A +
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et
> >>>>>> SQL
> >>>>>> Le site sur le langage SQL et les SGBDR :
> >>>>>> http://sqlpro.developpez.com
> >>>>>> Audit, conseil, expertise, formation, modélisation, tuning,
> >>>>>> optimisation
> >>>>>> ********************* http://www.datasapiens.com
> >>>>>> ***********************
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
> --
> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
> ********************* http://www.datasapiens.com ***********************
>
Merci pour votre article mais malheureusement cela ne résoud pas mon
J'avais plusieurs table temporaire dans ma SP qui sont utiliser lors de la
manipulation des données. A la fin j'insère tout dans une vrai table et je
fais un select de cette table. Les fonctions ne permettent pas d'utiliser
tables temporaire, donc je ne peux pas les utiliser. De plus dans mon
il y a un ORDER by donc je ne pourrais même pas l'utiliser dans ma vue....
Alors que faire ...?
"SQLpro [MVP]" a écrit :
> ILyasse a écrit :
> > Ok j'ai trouvé, mais le problème c'est que ma SP utilise des table
> > temporaire, chose qu'on ne peut pas faire dans une vue ou une
> > Alors que faire...?
>
> mais si !!!!
> Lisez l'article que j'ai écrit à ce sujet :
> http://sqlpro.developpez.com/cours/sqlserver/transactsql/#L3.2
>
>
> Après vous pouvez faire par exemple :
>
> SELECT *
> FROM dbo.MaFonction(...)
>
> A +
>
>
> >
> > "bruno reiter" a écrit :
> >
> >> select ... from UDF_xxx where ...
> >>
> >> br
> >>
> >>
> >> "ILyasse" a écrit dans le message
> >> news:
> >>> Mais alors comment appellé cette fonction dans la vue.
> >>> SELECT my_function from quoi ?... C'est ce que je ne comprend pas
> >>> bien
> >>> ...
> >>>
> >>> "bruno reiter" a écrit :
> >>>
> >>>> non, la fonction ne pourra pas appeler la SP, mais la fonction peut
> >>>> exactement ce que fait la SP
> >>>>
> >>>> br
> >>>>
> >>>> "ILyasse" a écrit dans le
> >>>> news:
> >>>>> Ce n'est pas si absurde qu'on le croit. Normalement je n'ai pas
> >>>>> d'une
> >>>>> view. J'exécute la SP et j'ai les résultat. Le problème est que
> >>>>> SP
> >>>>> sera
> >>>>> appellé par un Rapport Crystal , jusqu'ici ça va. Mais le hic
> >>>>> le
> >>>>> rapport crystal utilisera des paramètre. Et il semble que Crystal
> >>>>> Report
> >>>>> lorsqu'il utilise paramètre, génére une requête SQL du genre
> >>>>> where
> >>>>> parameter.... . Malheureusement un Select sur une SP ne
> >>>>> J'obtiens
> >>>>> donc un message d'erreur dans crystal disant 'Failes to open
> >>>>> Alors
> >>>>> que la SP fonctionne bien. DOnc je me suis dis je vais créer une
> >>>>> et
> >>>>> cette view fera appelle a cette SP. Et un rapport crystal qui
> >>>>> un
> >>>>> paramètre fonctionne très bien sur une view...
> >>>>>
> >>>>> Une solution pourrait être d'utiliser une fonction, mais alors
> >>>>> fonction sera en fait la stored procedure. Mais la stored
> >>>>> renvoie
> >>>>> plusieurs colonne, est-ce que cela ne causerai pas un problème.
> >>>>>
> >>>>> Exemple:
> >>>>> CREATE My_StoredPRoc as Select * from authors....
> >>>>>
> >>>>> Create function My_Function as exec My_StoredProc...
> >>>>>
> >>>>> Comment appellé cette fonction dans la vue ?
> >>>>>
> >>>>> CREATE VIEW My_view...
> >>>>>
> >>>>> Select My_Function from QUOI ? (from authors ?)
> >>>>>
> >>>>>
> >>>>> "SQLpro [MVP]" a écrit :
> >>>>>
> >>>>>> ILyasse a écrit :
> >>>>>>> Bonjour,
> >>>>>>>
> >>>>>>> J'amerai savoir si elle est possible de faire appelle à une
> >>>>>>> procedure
> >>>>>>> a partir d'nue view.
> >>>>>>> J'utilise Sql server 2000. Sachant que la stored procedure
> >>>>>>> une
> >>>>>>> table
> >>>>>>> et à la fin fait un select de cette table. Je voudrai faire une
> >>>>>>> qui me
> >>>>>>> renvoie le résultat de ce select.
> >>>>>>>
> >>>>>>> Merci d'avance pour votre aide.
> >>>>>>>
> >>>>>>>
> >>>>>> C'est totalement absurde :
> >>>>>>
> >>>>>> Une SP peut encapsuler de nombreuses requêtes et gérer de
> >>>>>> transactions.
> >>>>>> Or une requête EST une transaction.
> >>>>>> On ne peut donc appeler une SP dans une requête pour la bonne et
> >>>>>> simple
> >>>>>> raison qu'il ne peut y avoir un fractionnement de transactions à
> >>>>>> l'intérieur d'un SELECT par exemple !!! Cela permettrait de
> >>>>>> transaction SELECT non atomique ... ce qui est parfaitement
> >>>>>>
> >>>>>> En revanche une fonction ne peut pas contenir une transaction.
> >>>>>> peut
> >>>>>> donc (et c'est son rôle) être appelée dans un ordre SQL
> >>>>>> (SELECT, INSERT, UPDATE, DELETE...)
> >>>>>>
> >>>>>>
> >>>>>> De plus une SP qui execute un SELECT final peut être vu comme une
> >>>>>> requête SELECT. DOnc, ne changez rien à votre code. Ouvrez
> >>>>>> le
> >>>>>> curseur côté client pour voir les données qui sont renvoyées par
> >>>>>> SP.
> >>>>>>
> >>>>>> A +
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et
> >>>>>> SQL
> >>>>>> Le site sur le langage SQL et les SGBDR :
> >>>>>> http://sqlpro.developpez.com
> >>>>>> Audit, conseil, expertise, formation, modélisation, tuning,
> >>>>>> optimisation
> >>>>>> ********************* http://www.datasapiens.com
> >>>>>> ***********************
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
> --
> Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
> Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
> Audit, conseil, expertise, formation, modélisation, tuning, optimisation
> ********************* http://www.datasapiens.com ***********************
>
On peut créer des tables temporaires dans une fonction.
La synthaxe est :
DECLARE @temp TABLE (col 1 int not null, .....)
"ILyasse" a écrit dans le message de
news:
> Merci pour votre article mais malheureusement cela ne résoud pas mon
problème.
> J'avais plusieurs table temporaire dans ma SP qui sont utiliser lors de la
> manipulation des données. A la fin j'insère tout dans une vrai table et je
> fais un select de cette table. Les fonctions ne permettent pas d'utiliser
des
> tables temporaire, donc je ne peux pas les utiliser. De plus dans mon
select
> il y a un ORDER by donc je ne pourrais même pas l'utiliser dans ma vue....
> Alors que faire ...?
>
> "SQLpro [MVP]" a écrit :
>
> > ILyasse a écrit :
> > > Ok j'ai trouvé, mais le problème c'est que ma SP utilise des table
> > > temporaire, chose qu'on ne peut pas faire dans une vue ou une
fonction...
> > > Alors que faire...?
> >
> > mais si !!!!
> > Lisez l'article que j'ai écrit à ce sujet :
> > http://sqlpro.developpez.com/cours/sqlserver/transactsql/#L3.2
> >
> >
> > Après vous pouvez faire par exemple :
> >
> > SELECT *
> > FROM dbo.MaFonction(...)
> >
> > A +
> >
> >
> > >
> > > "bruno reiter" a écrit :
> > >
> > >> select ... from UDF_xxx where ...
> > >>
> > >> br
> > >>
> > >>
> > >> "ILyasse" a écrit dans le message
de
> > >> news:
> > >>> Mais alors comment appellé cette fonction dans la vue.
> > >>> SELECT my_function from quoi ?... C'est ce que je ne comprend pas
très
> > >>> bien
> > >>> ...
> > >>>
> > >>> "bruno reiter" a écrit :
> > >>>
> > >>>> non, la fonction ne pourra pas appeler la SP, mais la fonction peut
faire
> > >>>> exactement ce que fait la SP
> > >>>>
> > >>>> br
> > >>>>
> > >>>> "ILyasse" a écrit dans le
message de
> > >>>> news:
> > >>>>> Ce n'est pas si absurde qu'on le croit. Normalement je n'ai pas
besoid
> > >>>>> d'une
> > >>>>> view. J'exécute la SP et j'ai les résultat. Le problème est que
cette
> > >>>>> SP
> > >>>>> sera
> > >>>>> appellé par un Rapport Crystal , jusqu'ici ça va. Mais le hic
c'est que
> > >>>>> le
> > >>>>> rapport crystal utilisera des paramètre. Et il semble que Crystal
> > >>>>> Report
> > >>>>> lorsqu'il utilise paramètre, génére une requête SQL du genre
SELECT....
> > >>>>> where
> > >>>>> parameter.... . Malheureusement un Select sur une SP ne
fonctionne.
> > >>>>> J'obtiens
> > >>>>> donc un message d'erreur dans crystal disant 'Failes to open
Rowset'.
> > >>>>> Alors
> > >>>>> que la SP fonctionne bien. DOnc je me suis dis je vais créer une
view
> > >>>>> et
> > >>>>> cette view fera appelle a cette SP. Et un rapport crystal qui
utilise
> > >>>>> un
> > >>>>> paramètre fonctionne très bien sur une view...
> > >>>>>
> > >>>>> Une solution pourrait être d'utiliser une fonction, mais alors
cette
> > >>>>> fonction sera en fait la stored procedure. Mais la stored
procedure
> > >>>>> renvoie
> > >>>>> plusieurs colonne, est-ce que cela ne causerai pas un problème.
> > >>>>>
> > >>>>> Exemple:
> > >>>>> CREATE My_StoredPRoc as Select * from authors....
> > >>>>>
> > >>>>> Create function My_Function as exec My_StoredProc...
> > >>>>>
> > >>>>> Comment appellé cette fonction dans la vue ?
> > >>>>>
> > >>>>> CREATE VIEW My_view...
> > >>>>>
> > >>>>> Select My_Function from QUOI ? (from authors ?)
> > >>>>>
> > >>>>>
> > >>>>> "SQLpro [MVP]" a écrit :
> > >>>>>
> > >>>>>> ILyasse a écrit :
> > >>>>>>> Bonjour,
> > >>>>>>>
> > >>>>>>> J'amerai savoir si elle est possible de faire appelle à une
stored
> > >>>>>>> procedure
> > >>>>>>> a partir d'nue view.
> > >>>>>>> J'utilise Sql server 2000. Sachant que la stored procedure
rempli
> > >>>>>>> une
> > >>>>>>> table
> > >>>>>>> et à la fin fait un select de cette table. Je voudrai faire une
view
> > >>>>>>> qui me
> > >>>>>>> renvoie le résultat de ce select.
> > >>>>>>>
> > >>>>>>> Merci d'avance pour votre aide.
> > >>>>>>>
> > >>>>>>>
> > >>>>>> C'est totalement absurde :
> > >>>>>>
> > >>>>>> Une SP peut encapsuler de nombreuses requêtes et gérer de
multiples
> > >>>>>> transactions.
> > >>>>>> Or une requête EST une transaction.
> > >>>>>> On ne peut donc appeler une SP dans une requête pour la bonne et
> > >>>>>> simple
> > >>>>>> raison qu'il ne peut y avoir un fractionnement de transactions à
> > >>>>>> l'intérieur d'un SELECT par exemple !!! Cela permettrait de
rendre la
> > >>>>>> transaction SELECT non atomique ... ce qui est parfaitement
absurde.
> > >>>>>>
> > >>>>>> En revanche une fonction ne peut pas contenir une transaction.
Elle
> > >>>>>> peut
> > >>>>>> donc (et c'est son rôle) être appelée dans un ordre SQL
quelconque
> > >>>>>> (SELECT, INSERT, UPDATE, DELETE...)
> > >>>>>>
> > >>>>>>
> > >>>>>> De plus une SP qui execute un SELECT final peut être vu comme une
> > >>>>>> requête SELECT. DOnc, ne changez rien à votre code. Ouvrez
simplement
> > >>>>>> le
> > >>>>>> curseur côté client pour voir les données qui sont renvoyées par
la
> > >>>>>> SP.
> > >>>>>>
> > >>>>>> A +
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et
langage
> > >>>>>> SQL
> > >>>>>> Le site sur le langage SQL et les SGBDR :
> > >>>>>> http://sqlpro.developpez.com
> > >>>>>> Audit, conseil, expertise, formation, modélisation, tuning,
> > >>>>>> optimisation
> > >>>>>> ********************* http://www.datasapiens.com
> > >>>>>> ***********************
> > >>>>>>
> > >>>>
> > >>>>
> > >>
> > >>
> >
> >
> > --
> > Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
> > Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
> > Audit, conseil, expertise, formation, modélisation, tuning, optimisation
> > ********************* http://www.datasapiens.com ***********************
> >
On peut créer des tables temporaires dans une fonction.
La synthaxe est :
DECLARE @temp TABLE (col 1 int not null, .....)
"ILyasse" <ILyasse@discussions.microsoft.com> a écrit dans le message de
news:8639849F-11E6-4053-A8F8-7CF4148F4030@microsoft.com...
> Merci pour votre article mais malheureusement cela ne résoud pas mon
problème.
> J'avais plusieurs table temporaire dans ma SP qui sont utiliser lors de la
> manipulation des données. A la fin j'insère tout dans une vrai table et je
> fais un select de cette table. Les fonctions ne permettent pas d'utiliser
des
> tables temporaire, donc je ne peux pas les utiliser. De plus dans mon
select
> il y a un ORDER by donc je ne pourrais même pas l'utiliser dans ma vue....
> Alors que faire ...?
>
> "SQLpro [MVP]" a écrit :
>
> > ILyasse a écrit :
> > > Ok j'ai trouvé, mais le problème c'est que ma SP utilise des table
> > > temporaire, chose qu'on ne peut pas faire dans une vue ou une
fonction...
> > > Alors que faire...?
> >
> > mais si !!!!
> > Lisez l'article que j'ai écrit à ce sujet :
> > http://sqlpro.developpez.com/cours/sqlserver/transactsql/#L3.2
> >
> >
> > Après vous pouvez faire par exemple :
> >
> > SELECT *
> > FROM dbo.MaFonction(...)
> >
> > A +
> >
> >
> > >
> > > "bruno reiter" a écrit :
> > >
> > >> select ... from UDF_xxx where ...
> > >>
> > >> br
> > >>
> > >>
> > >> "ILyasse" <ILyasse@discussions.microsoft.com> a écrit dans le message
de
> > >> news: 9924A723-67D3-438B-BFD1-565F9ADE3727@microsoft.com...
> > >>> Mais alors comment appellé cette fonction dans la vue.
> > >>> SELECT my_function from quoi ?... C'est ce que je ne comprend pas
très
> > >>> bien
> > >>> ...
> > >>>
> > >>> "bruno reiter" a écrit :
> > >>>
> > >>>> non, la fonction ne pourra pas appeler la SP, mais la fonction peut
faire
> > >>>> exactement ce que fait la SP
> > >>>>
> > >>>> br
> > >>>>
> > >>>> "ILyasse" <ILyasse@discussions.microsoft.com> a écrit dans le
message de
> > >>>> news: DBAAE2EC-611A-4D51-A2B0-B5633F0E6267@microsoft.com...
> > >>>>> Ce n'est pas si absurde qu'on le croit. Normalement je n'ai pas
besoid
> > >>>>> d'une
> > >>>>> view. J'exécute la SP et j'ai les résultat. Le problème est que
cette
> > >>>>> SP
> > >>>>> sera
> > >>>>> appellé par un Rapport Crystal , jusqu'ici ça va. Mais le hic
c'est que
> > >>>>> le
> > >>>>> rapport crystal utilisera des paramètre. Et il semble que Crystal
> > >>>>> Report
> > >>>>> lorsqu'il utilise paramètre, génére une requête SQL du genre
SELECT....
> > >>>>> where
> > >>>>> parameter.... . Malheureusement un Select sur une SP ne
fonctionne.
> > >>>>> J'obtiens
> > >>>>> donc un message d'erreur dans crystal disant 'Failes to open
Rowset'.
> > >>>>> Alors
> > >>>>> que la SP fonctionne bien. DOnc je me suis dis je vais créer une
view
> > >>>>> et
> > >>>>> cette view fera appelle a cette SP. Et un rapport crystal qui
utilise
> > >>>>> un
> > >>>>> paramètre fonctionne très bien sur une view...
> > >>>>>
> > >>>>> Une solution pourrait être d'utiliser une fonction, mais alors
cette
> > >>>>> fonction sera en fait la stored procedure. Mais la stored
procedure
> > >>>>> renvoie
> > >>>>> plusieurs colonne, est-ce que cela ne causerai pas un problème.
> > >>>>>
> > >>>>> Exemple:
> > >>>>> CREATE My_StoredPRoc as Select * from authors....
> > >>>>>
> > >>>>> Create function My_Function as exec My_StoredProc...
> > >>>>>
> > >>>>> Comment appellé cette fonction dans la vue ?
> > >>>>>
> > >>>>> CREATE VIEW My_view...
> > >>>>>
> > >>>>> Select My_Function from QUOI ? (from authors ?)
> > >>>>>
> > >>>>>
> > >>>>> "SQLpro [MVP]" a écrit :
> > >>>>>
> > >>>>>> ILyasse a écrit :
> > >>>>>>> Bonjour,
> > >>>>>>>
> > >>>>>>> J'amerai savoir si elle est possible de faire appelle à une
stored
> > >>>>>>> procedure
> > >>>>>>> a partir d'nue view.
> > >>>>>>> J'utilise Sql server 2000. Sachant que la stored procedure
rempli
> > >>>>>>> une
> > >>>>>>> table
> > >>>>>>> et à la fin fait un select de cette table. Je voudrai faire une
view
> > >>>>>>> qui me
> > >>>>>>> renvoie le résultat de ce select.
> > >>>>>>>
> > >>>>>>> Merci d'avance pour votre aide.
> > >>>>>>>
> > >>>>>>>
> > >>>>>> C'est totalement absurde :
> > >>>>>>
> > >>>>>> Une SP peut encapsuler de nombreuses requêtes et gérer de
multiples
> > >>>>>> transactions.
> > >>>>>> Or une requête EST une transaction.
> > >>>>>> On ne peut donc appeler une SP dans une requête pour la bonne et
> > >>>>>> simple
> > >>>>>> raison qu'il ne peut y avoir un fractionnement de transactions à
> > >>>>>> l'intérieur d'un SELECT par exemple !!! Cela permettrait de
rendre la
> > >>>>>> transaction SELECT non atomique ... ce qui est parfaitement
absurde.
> > >>>>>>
> > >>>>>> En revanche une fonction ne peut pas contenir une transaction.
Elle
> > >>>>>> peut
> > >>>>>> donc (et c'est son rôle) être appelée dans un ordre SQL
quelconque
> > >>>>>> (SELECT, INSERT, UPDATE, DELETE...)
> > >>>>>>
> > >>>>>>
> > >>>>>> De plus une SP qui execute un SELECT final peut être vu comme une
> > >>>>>> requête SELECT. DOnc, ne changez rien à votre code. Ouvrez
simplement
> > >>>>>> le
> > >>>>>> curseur côté client pour voir les données qui sont renvoyées par
la
> > >>>>>> SP.
> > >>>>>>
> > >>>>>> A +
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et
langage
> > >>>>>> SQL
> > >>>>>> Le site sur le langage SQL et les SGBDR :
> > >>>>>> http://sqlpro.developpez.com
> > >>>>>> Audit, conseil, expertise, formation, modélisation, tuning,
> > >>>>>> optimisation
> > >>>>>> ********************* http://www.datasapiens.com
> > >>>>>> ***********************
> > >>>>>>
> > >>>>
> > >>>>
> > >>
> > >>
> >
> >
> > --
> > Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
> > Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
> > Audit, conseil, expertise, formation, modélisation, tuning, optimisation
> > ********************* http://www.datasapiens.com ***********************
> >
On peut créer des tables temporaires dans une fonction.
La synthaxe est :
DECLARE @temp TABLE (col 1 int not null, .....)
"ILyasse" a écrit dans le message de
news:
> Merci pour votre article mais malheureusement cela ne résoud pas mon
problème.
> J'avais plusieurs table temporaire dans ma SP qui sont utiliser lors de la
> manipulation des données. A la fin j'insère tout dans une vrai table et je
> fais un select de cette table. Les fonctions ne permettent pas d'utiliser
des
> tables temporaire, donc je ne peux pas les utiliser. De plus dans mon
select
> il y a un ORDER by donc je ne pourrais même pas l'utiliser dans ma vue....
> Alors que faire ...?
>
> "SQLpro [MVP]" a écrit :
>
> > ILyasse a écrit :
> > > Ok j'ai trouvé, mais le problème c'est que ma SP utilise des table
> > > temporaire, chose qu'on ne peut pas faire dans une vue ou une
fonction...
> > > Alors que faire...?
> >
> > mais si !!!!
> > Lisez l'article que j'ai écrit à ce sujet :
> > http://sqlpro.developpez.com/cours/sqlserver/transactsql/#L3.2
> >
> >
> > Après vous pouvez faire par exemple :
> >
> > SELECT *
> > FROM dbo.MaFonction(...)
> >
> > A +
> >
> >
> > >
> > > "bruno reiter" a écrit :
> > >
> > >> select ... from UDF_xxx where ...
> > >>
> > >> br
> > >>
> > >>
> > >> "ILyasse" a écrit dans le message
de
> > >> news:
> > >>> Mais alors comment appellé cette fonction dans la vue.
> > >>> SELECT my_function from quoi ?... C'est ce que je ne comprend pas
très
> > >>> bien
> > >>> ...
> > >>>
> > >>> "bruno reiter" a écrit :
> > >>>
> > >>>> non, la fonction ne pourra pas appeler la SP, mais la fonction peut
faire
> > >>>> exactement ce que fait la SP
> > >>>>
> > >>>> br
> > >>>>
> > >>>> "ILyasse" a écrit dans le
message de
> > >>>> news:
> > >>>>> Ce n'est pas si absurde qu'on le croit. Normalement je n'ai pas
besoid
> > >>>>> d'une
> > >>>>> view. J'exécute la SP et j'ai les résultat. Le problème est que
cette
> > >>>>> SP
> > >>>>> sera
> > >>>>> appellé par un Rapport Crystal , jusqu'ici ça va. Mais le hic
c'est que
> > >>>>> le
> > >>>>> rapport crystal utilisera des paramètre. Et il semble que Crystal
> > >>>>> Report
> > >>>>> lorsqu'il utilise paramètre, génére une requête SQL du genre
SELECT....
> > >>>>> where
> > >>>>> parameter.... . Malheureusement un Select sur une SP ne
fonctionne.
> > >>>>> J'obtiens
> > >>>>> donc un message d'erreur dans crystal disant 'Failes to open
Rowset'.
> > >>>>> Alors
> > >>>>> que la SP fonctionne bien. DOnc je me suis dis je vais créer une
view
> > >>>>> et
> > >>>>> cette view fera appelle a cette SP. Et un rapport crystal qui
utilise
> > >>>>> un
> > >>>>> paramètre fonctionne très bien sur une view...
> > >>>>>
> > >>>>> Une solution pourrait être d'utiliser une fonction, mais alors
cette
> > >>>>> fonction sera en fait la stored procedure. Mais la stored
procedure
> > >>>>> renvoie
> > >>>>> plusieurs colonne, est-ce que cela ne causerai pas un problème.
> > >>>>>
> > >>>>> Exemple:
> > >>>>> CREATE My_StoredPRoc as Select * from authors....
> > >>>>>
> > >>>>> Create function My_Function as exec My_StoredProc...
> > >>>>>
> > >>>>> Comment appellé cette fonction dans la vue ?
> > >>>>>
> > >>>>> CREATE VIEW My_view...
> > >>>>>
> > >>>>> Select My_Function from QUOI ? (from authors ?)
> > >>>>>
> > >>>>>
> > >>>>> "SQLpro [MVP]" a écrit :
> > >>>>>
> > >>>>>> ILyasse a écrit :
> > >>>>>>> Bonjour,
> > >>>>>>>
> > >>>>>>> J'amerai savoir si elle est possible de faire appelle à une
stored
> > >>>>>>> procedure
> > >>>>>>> a partir d'nue view.
> > >>>>>>> J'utilise Sql server 2000. Sachant que la stored procedure
rempli
> > >>>>>>> une
> > >>>>>>> table
> > >>>>>>> et à la fin fait un select de cette table. Je voudrai faire une
view
> > >>>>>>> qui me
> > >>>>>>> renvoie le résultat de ce select.
> > >>>>>>>
> > >>>>>>> Merci d'avance pour votre aide.
> > >>>>>>>
> > >>>>>>>
> > >>>>>> C'est totalement absurde :
> > >>>>>>
> > >>>>>> Une SP peut encapsuler de nombreuses requêtes et gérer de
multiples
> > >>>>>> transactions.
> > >>>>>> Or une requête EST une transaction.
> > >>>>>> On ne peut donc appeler une SP dans une requête pour la bonne et
> > >>>>>> simple
> > >>>>>> raison qu'il ne peut y avoir un fractionnement de transactions à
> > >>>>>> l'intérieur d'un SELECT par exemple !!! Cela permettrait de
rendre la
> > >>>>>> transaction SELECT non atomique ... ce qui est parfaitement
absurde.
> > >>>>>>
> > >>>>>> En revanche une fonction ne peut pas contenir une transaction.
Elle
> > >>>>>> peut
> > >>>>>> donc (et c'est son rôle) être appelée dans un ordre SQL
quelconque
> > >>>>>> (SELECT, INSERT, UPDATE, DELETE...)
> > >>>>>>
> > >>>>>>
> > >>>>>> De plus une SP qui execute un SELECT final peut être vu comme une
> > >>>>>> requête SELECT. DOnc, ne changez rien à votre code. Ouvrez
simplement
> > >>>>>> le
> > >>>>>> curseur côté client pour voir les données qui sont renvoyées par
la
> > >>>>>> SP.
> > >>>>>>
> > >>>>>> A +
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> Frédéric BROUARD, MVP SQL Server, expert bases de données et
langage
> > >>>>>> SQL
> > >>>>>> Le site sur le langage SQL et les SGBDR :
> > >>>>>> http://sqlpro.developpez.com
> > >>>>>> Audit, conseil, expertise, formation, modélisation, tuning,
> > >>>>>> optimisation
> > >>>>>> ********************* http://www.datasapiens.com
> > >>>>>> ***********************
> > >>>>>>
> > >>>>
> > >>>>
> > >>
> > >>
> >
> >
> > --
> > Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
> > Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
> > Audit, conseil, expertise, formation, modélisation, tuning, optimisation
> > ********************* http://www.datasapiens.com ***********************
> >
