Bonjour,
J'utilise une application qui se trouve être installée sur le même serveur
que SQL Serveur. Naturellement comme l'ensemble est bien configuré,
l'application et SQL dialogue via TCP/IP au lieu de Shared Memory. Ce serveur
est équipé de 4 cartes réseaux pour différents besoin et aucune configuration
particuliére est réalisée au niveau de la configuration réseau de SQL Serveur
, j'écoute donc sur toute les cartes.
Cette configuration est elle génératrice d'une chargé réseau où le traffic
entre l'application et SQL server reste local et n'emet rien sur le réseau ?
Sur quel carte va répondre SQL Serveur à l'application ?
Merci pour vos réponses.
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
SQL Server ecoute sur toutes les cartes presentes et repond au coup par coup a la carte qui l'interroge
-- Bien cordialement Med Bouchenafa
"nono" wrote in message news:
Bonjour, J'utilise une application qui se trouve être installée sur le même serveur que SQL Serveur. Naturellement comme l'ensemble est bien configuré, l'application et SQL dialogue via TCP/IP au lieu de Shared Memory. Ce serveur est équipé de 4 cartes réseaux pour différents besoin et aucune configuration particuliére est réalisée au niveau de la configuration réseau de SQL Serveur , j'écoute donc sur toute les cartes. Cette configuration est elle génératrice d'une chargé réseau où le traffic entre l'application et SQL server reste local et n'emet rien sur le réseau ? Sur quel carte va répondre SQL Serveur à l'application ? Merci pour vos réponses.
SQL Server ecoute sur toutes les cartes presentes et repond au coup par coup
a la carte qui l'interroge
--
Bien cordialement
Med Bouchenafa
"nono" <nono@discussions.microsoft.com> wrote in message
news:73DC11CA-801D-4CA6-B555-6BAFD13A7ABF@microsoft.com...
Bonjour,
J'utilise une application qui se trouve être installée sur le même serveur
que SQL Serveur. Naturellement comme l'ensemble est bien configuré,
l'application et SQL dialogue via TCP/IP au lieu de Shared Memory. Ce
serveur
est équipé de 4 cartes réseaux pour différents besoin et aucune
configuration
particuliére est réalisée au niveau de la configuration réseau de SQL
Serveur
, j'écoute donc sur toute les cartes.
Cette configuration est elle génératrice d'une chargé réseau où le traffic
entre l'application et SQL server reste local et n'emet rien sur le réseau
?
Sur quel carte va répondre SQL Serveur à l'application ?
Merci pour vos réponses.
SQL Server ecoute sur toutes les cartes presentes et repond au coup par coup a la carte qui l'interroge
-- Bien cordialement Med Bouchenafa
"nono" wrote in message news:
Bonjour, J'utilise une application qui se trouve être installée sur le même serveur que SQL Serveur. Naturellement comme l'ensemble est bien configuré, l'application et SQL dialogue via TCP/IP au lieu de Shared Memory. Ce serveur est équipé de 4 cartes réseaux pour différents besoin et aucune configuration particuliére est réalisée au niveau de la configuration réseau de SQL Serveur , j'écoute donc sur toute les cartes. Cette configuration est elle génératrice d'une chargé réseau où le traffic entre l'application et SQL server reste local et n'emet rien sur le réseau ? Sur quel carte va répondre SQL Serveur à l'application ? Merci pour vos réponses.
Philippe T [MS]
Bonjour,
Elle peut également utiliser l'interface Loopback je crois.
---------------------------------------------------------------------- Philippe TROTIN - Microsoft Service France
"nono" wrote in message news:
Bonjour, J'utilise une application qui se trouve être installée sur le même serveur que SQL Serveur. Naturellement comme l'ensemble est bien configuré, l'application et SQL dialogue via TCP/IP au lieu de Shared Memory. Ce serveur est équipé de 4 cartes réseaux pour différents besoin et aucune configuration particuliére est réalisée au niveau de la configuration réseau de SQL Serveur , j'écoute donc sur toute les cartes. Cette configuration est elle génératrice d'une chargé réseau où le traffic entre l'application et SQL server reste local et n'emet rien sur le réseau ? Sur quel carte va répondre SQL Serveur à l'application ? Merci pour vos réponses.
Bonjour,
Elle peut également utiliser l'interface Loopback je crois.
----------------------------------------------------------------------
Philippe TROTIN - Microsoft Service France
"nono" <nono@discussions.microsoft.com> wrote in message
news:73DC11CA-801D-4CA6-B555-6BAFD13A7ABF@microsoft.com...
Bonjour,
J'utilise une application qui se trouve être installée sur le même serveur
que SQL Serveur. Naturellement comme l'ensemble est bien configuré,
l'application et SQL dialogue via TCP/IP au lieu de Shared Memory. Ce
serveur
est équipé de 4 cartes réseaux pour différents besoin et aucune
configuration
particuliére est réalisée au niveau de la configuration réseau de SQL
Serveur
, j'écoute donc sur toute les cartes.
Cette configuration est elle génératrice d'une chargé réseau où le traffic
entre l'application et SQL server reste local et n'emet rien sur le réseau
?
Sur quel carte va répondre SQL Serveur à l'application ?
Merci pour vos réponses.
Elle peut également utiliser l'interface Loopback je crois.
---------------------------------------------------------------------- Philippe TROTIN - Microsoft Service France
"nono" wrote in message news:
Bonjour, J'utilise une application qui se trouve être installée sur le même serveur que SQL Serveur. Naturellement comme l'ensemble est bien configuré, l'application et SQL dialogue via TCP/IP au lieu de Shared Memory. Ce serveur est équipé de 4 cartes réseaux pour différents besoin et aucune configuration particuliére est réalisée au niveau de la configuration réseau de SQL Serveur , j'écoute donc sur toute les cartes. Cette configuration est elle génératrice d'une chargé réseau où le traffic entre l'application et SQL server reste local et n'emet rien sur le réseau ? Sur quel carte va répondre SQL Serveur à l'application ? Merci pour vos réponses.