Je redoute le pire. Soit un système SQL server contenant plusieurs bases.
dans le cas d'une connexion unique, la variable @@FETCH_STATUS est globale :
pour l'ensemble du système SQL Server ?
ou
par base. ?
Merci.
LM
Click here to answer / cliquez ci dessous pour me répondre directement
http://cerbermail.com/?LBYq8YUwyz
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
Med Bouchenafa
@@FETCH_STATUS est specifique à une connexion et pas à une base de données C'est quoi le pire? Il y a toujours des solutions de contournement -- Bien cordialement Med Bouchenafa
"LuckyMan" a écrit :
Bonjour,
Je redoute le pire. Soit un système SQL server contenant plusieurs bases. dans le cas d'une connexion unique, la variable @@FETCH_STATUS est globale : pour l'ensemble du système SQL Server ? ou par base. ?
Merci.
LM
Click here to answer / cliquez ci dessous pour me répondre directement http://cerbermail.com/?LBYq8YUwyz
@@FETCH_STATUS est specifique à une connexion et pas à une base de données
C'est quoi le pire?
Il y a toujours des solutions de contournement
--
Bien cordialement
Med Bouchenafa
"LuckyMan" a écrit :
Bonjour,
Je redoute le pire. Soit un système SQL server contenant plusieurs bases.
dans le cas d'une connexion unique, la variable @@FETCH_STATUS est globale :
pour l'ensemble du système SQL Server ?
ou
par base. ?
Merci.
LM
Click here to answer / cliquez ci dessous pour me répondre directement
http://cerbermail.com/?LBYq8YUwyz
@@FETCH_STATUS est specifique à une connexion et pas à une base de données C'est quoi le pire? Il y a toujours des solutions de contournement -- Bien cordialement Med Bouchenafa
"LuckyMan" a écrit :
Bonjour,
Je redoute le pire. Soit un système SQL server contenant plusieurs bases. dans le cas d'une connexion unique, la variable @@FETCH_STATUS est globale : pour l'ensemble du système SQL Server ? ou par base. ?
Merci.
LM
Click here to answer / cliquez ci dessous pour me répondre directement http://cerbermail.com/?LBYq8YUwyz
Fred BROUARD
La plupart des variables @@ utilisées dans les programmes sont propres à la session : @@IDENTITY @@DATEFIRST @@ERROR @@ROWCOUNT @@TRANCOUNT ...
A +
LuckyMan a écrit:
Bonjour,
Je redoute le pire. Soit un système SQL server contenant plusieurs bases. dans le cas d'une connexion unique, la variable @@FETCH_STATUS est globale : pour l'ensemble du système SQL Server ? ou par base. ?
Merci.
LM
Click here to answer / cliquez ci dessous pour me répondre directement http://cerbermail.com/?LBYq8YUwyz
-- 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 ***********************
La plupart des variables @@ utilisées dans les programmes sont propres à la
session :
@@IDENTITY
@@DATEFIRST
@@ERROR
@@ROWCOUNT
@@TRANCOUNT
...
A +
LuckyMan a écrit:
Bonjour,
Je redoute le pire. Soit un système SQL server contenant plusieurs bases.
dans le cas d'une connexion unique, la variable @@FETCH_STATUS est globale :
pour l'ensemble du système SQL Server ?
ou
par base. ?
Merci.
LM
Click here to answer / cliquez ci dessous pour me répondre directement
http://cerbermail.com/?LBYq8YUwyz
--
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 ***********************
La plupart des variables @@ utilisées dans les programmes sont propres à la session : @@IDENTITY @@DATEFIRST @@ERROR @@ROWCOUNT @@TRANCOUNT ...
A +
LuckyMan a écrit:
Bonjour,
Je redoute le pire. Soit un système SQL server contenant plusieurs bases. dans le cas d'une connexion unique, la variable @@FETCH_STATUS est globale : pour l'ensemble du système SQL Server ? ou par base. ?
Merci.
LM
Click here to answer / cliquez ci dessous pour me répondre directement http://cerbermail.com/?LBYq8YUwyz
-- 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 ***********************
LuckyMan
Fred BROUARD wrote:
La plupart des variables @@ utilisées dans les programmes sont propres à la session : @@IDENTITY @@DATEFIRST @@ERROR @@ROWCOUNT @@TRANCOUNT ...
Merci à Tous,
Reste pour moi à comprendre ce qu'est une session au sens SQL. Mais il me semble plus prudent d'éviter ces variables dans des triggers ou SP appelées par un trigger. Est-ce qu'en ouvrant deux fois une connexion ODBC avec la même connexion string on a deux sessions ? a priori oui
je cogite sur http://dotnetjunkies.com/Article/86F0988E-FED4-414F-BA2E-D01D953C11BE.dcik
LM
Fred BROUARD wrote:
La plupart des variables @@ utilisées dans les programmes sont
propres à la session :
@@IDENTITY
@@DATEFIRST
@@ERROR
@@ROWCOUNT
@@TRANCOUNT
...
Merci à Tous,
Reste pour moi à comprendre ce qu'est une session au sens SQL. Mais il me
semble plus prudent d'éviter ces variables dans des triggers ou SP appelées
par un trigger.
Est-ce qu'en ouvrant deux fois une connexion ODBC avec la même connexion
string on a deux sessions ? a priori oui
je cogite sur
http://dotnetjunkies.com/Article/86F0988E-FED4-414F-BA2E-D01D953C11BE.dcik
La plupart des variables @@ utilisées dans les programmes sont propres à la session : @@IDENTITY @@DATEFIRST @@ERROR @@ROWCOUNT @@TRANCOUNT ...
Merci à Tous,
Reste pour moi à comprendre ce qu'est une session au sens SQL. Mais il me semble plus prudent d'éviter ces variables dans des triggers ou SP appelées par un trigger. Est-ce qu'en ouvrant deux fois une connexion ODBC avec la même connexion string on a deux sessions ? a priori oui
je cogite sur http://dotnetjunkies.com/Article/86F0988E-FED4-414F-BA2E-D01D953C11BE.dcik
LM
Fred BROUARD
Bonjour,
Si vous voulez des explications détaillées sur ce qu'est une connexion et une session au sens normatif SQL du terme, vous pouvez vous reporter aux pages 64 à 66 et 307 à 30 de mon nouveau livre : http://sqlpro.developpez.com/booksql05/
En gros connexion et session sont intimement liées : avant l'authentification c'est une connexion, après, c'est une session. Chaque session est unique, même ouverte avec le même compte (user + password).
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 ***********************
LuckyMan a écrit:
Fred BROUARD wrote:
La plupart des variables @@ utilisées dans les programmes sont propres à la session : @@IDENTITY @@DATEFIRST @@ERROR @@ROWCOUNT @@TRANCOUNT ...
Merci à Tous,
Reste pour moi à comprendre ce qu'est une session au sens SQL. Mais il me semble plus prudent d'éviter ces variables dans des triggers ou SP appelées par un trigger. Est-ce qu'en ouvrant deux fois une connexion ODBC avec la même connexion string on a deux sessions ? a priori oui
je cogite sur http://dotnetjunkies.com/Article/86F0988E-FED4-414F-BA2E-D01D953C11BE.dcik
LM
Bonjour,
Si vous voulez des explications détaillées sur ce qu'est une connexion et une
session au sens normatif SQL du terme, vous pouvez vous reporter aux pages 64 à
66 et 307 à 30 de mon nouveau livre : http://sqlpro.developpez.com/booksql05/
En gros connexion et session sont intimement liées : avant l'authentification
c'est une connexion, après, c'est une session.
Chaque session est unique, même ouverte avec le même compte (user + password).
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 ***********************
LuckyMan a écrit:
Fred BROUARD wrote:
La plupart des variables @@ utilisées dans les programmes sont
propres à la session :
@@IDENTITY
@@DATEFIRST
@@ERROR
@@ROWCOUNT
@@TRANCOUNT
...
Merci à Tous,
Reste pour moi à comprendre ce qu'est une session au sens SQL. Mais il me
semble plus prudent d'éviter ces variables dans des triggers ou SP appelées
par un trigger.
Est-ce qu'en ouvrant deux fois une connexion ODBC avec la même connexion
string on a deux sessions ? a priori oui
je cogite sur
http://dotnetjunkies.com/Article/86F0988E-FED4-414F-BA2E-D01D953C11BE.dcik
Si vous voulez des explications détaillées sur ce qu'est une connexion et une session au sens normatif SQL du terme, vous pouvez vous reporter aux pages 64 à 66 et 307 à 30 de mon nouveau livre : http://sqlpro.developpez.com/booksql05/
En gros connexion et session sont intimement liées : avant l'authentification c'est une connexion, après, c'est une session. Chaque session est unique, même ouverte avec le même compte (user + password).
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 ***********************
LuckyMan a écrit:
Fred BROUARD wrote:
La plupart des variables @@ utilisées dans les programmes sont propres à la session : @@IDENTITY @@DATEFIRST @@ERROR @@ROWCOUNT @@TRANCOUNT ...
Merci à Tous,
Reste pour moi à comprendre ce qu'est une session au sens SQL. Mais il me semble plus prudent d'éviter ces variables dans des triggers ou SP appelées par un trigger. Est-ce qu'en ouvrant deux fois une connexion ODBC avec la même connexion string on a deux sessions ? a priori oui
je cogite sur http://dotnetjunkies.com/Article/86F0988E-FED4-414F-BA2E-D01D953C11BE.dcik
LM
LuckyMan
Fred BROUARD wrote:
Bonjour,
Si vous voulez des explications détaillées sur ce qu'est une connexion et une session au sens normatif SQL du terme, vous pouvez vous reporter aux pages 64 à 66 et 307 à 30 de mon nouveau livre : http://sqlpro.developpez.com/booksql05/
En gros connexion et session sont intimement liées : avant l'authentification c'est une connexion, après, c'est une session. Chaque session est unique, même ouverte avec le même compte (user + password).
Donc c'est bien cela, un curseur dans une routine boucle utilisant en control de sortie un @@FetchStatus et appelant dans la boucle un update ou une sp (triggé et utilisant un curseur avec un control de boucle par rapport au @@FetchStatus ), sera shunté pratiquement après le premier appel de l'update. Par contre il y a aucun risque avec d'autres utilisateurs connectés simultanément.
Fred BROUARD wrote:
Bonjour,
Si vous voulez des explications détaillées sur ce qu'est une
connexion et une session au sens normatif SQL du terme, vous pouvez
vous reporter aux pages 64 à 66 et 307 à 30 de mon nouveau livre :
http://sqlpro.developpez.com/booksql05/
En gros connexion et session sont intimement liées : avant
l'authentification c'est une connexion, après, c'est une session.
Chaque session est unique, même ouverte avec le même compte (user +
password).
Donc c'est bien cela, un curseur dans une routine boucle utilisant en
control de sortie un @@FetchStatus et appelant dans la boucle un update ou
une sp (triggé et utilisant un curseur avec un control de boucle par rapport
au @@FetchStatus ), sera shunté pratiquement après le premier appel de
l'update.
Par contre il y a aucun risque avec d'autres utilisateurs connectés
simultanément.
Si vous voulez des explications détaillées sur ce qu'est une connexion et une session au sens normatif SQL du terme, vous pouvez vous reporter aux pages 64 à 66 et 307 à 30 de mon nouveau livre : http://sqlpro.developpez.com/booksql05/
En gros connexion et session sont intimement liées : avant l'authentification c'est une connexion, après, c'est une session. Chaque session est unique, même ouverte avec le même compte (user + password).
Donc c'est bien cela, un curseur dans une routine boucle utilisant en control de sortie un @@FetchStatus et appelant dans la boucle un update ou une sp (triggé et utilisant un curseur avec un control de boucle par rapport au @@FetchStatus ), sera shunté pratiquement après le premier appel de l'update. Par contre il y a aucun risque avec d'autres utilisateurs connectés simultanément.
