l'utilisation des lib perl d'envoi de mail est incompatible avec SQL DMO.
Le script reste bloqué.
Le comportement est le meme pour ces 2 lib :
- SendMail
- Net::SMTP
l'utilisation des lib perl d'envoi de mail est incompatible avec SQL DMO.
Le script reste bloqué.
Le comportement est le meme pour ces 2 lib :
- SendMail
- Net::SMTP
l'utilisation des lib perl d'envoi de mail est incompatible avec SQL DMO.
Le script reste bloqué.
Le comportement est le meme pour ces 2 lib :
- SendMail
- Net::SMTP
Brigitte a écrit:
> l'utilisation des lib perl d'envoi de mail est incompatible avec SQL DMO.
> Le script reste bloqué.
> Le comportement est le meme pour ces 2 lib :
> - SendMail
> - Net::SMTP
Bonjour,
Il n'y a pas d'incompatibilité entre le DMO et des librairies Perl. SQL-DMO
est une suite d'objets COM, et n'a pas d'incidence sur la façon dont les
libraires Perl fonctionnent.
Ci-dessous un code d'exemple, testé avec ActivePerl 5.8.7, qui ne pose pas
de problème chez moi.
#--- code start ---
use strict;
use Win32::OLE 'in';
use Win32::OLE::Const 'Microsoft SQLDMO';
use Net::SMTP;
my $serverName = 'myServer';
my $SMTPServer = 'smtp.myserver.com';
my $recipients = [ '' ];
my $sender = '';
my $sub = 'test mail DMO';
my ($to, $from) = ('',
'' );
my $msg;
my @confs = ();
my $server = Win32::OLE->new('SQLDMO.SQLServer2')
or die "erreur de creation de l'objet SQLDMO";
my $smtp = Net::SMTP->new($SMTPServer)
or die "erreur de connexion au serveur SMTP $SMTPServer.";
$server->{LoginSecure} = 1;
$server->{LoginTimeout} = 30;
$server->connect($serverName);
! Win32::OLE->LastError() or
die "erreur de connexion a $serverName.";
foreach my $conf (in($server->Configuration->ConfigValues())) {
push @confs, $conf->{name};
}
$server->DisConnect();
$msg = join "n", @confs;
$smtp->mail($sender);
$smtp->to(@$recipients);
$smtp->data();
$smtp->datasend("Subject: $subn");
$smtp->datasend("To: $ton");
$smtp->datasend("From: $fromn");
$smtp->datasend("n");
$smtp->datasend("$msgn");
$smtp->datasend() or
die "erreur d'envoi au serveur SMTP";
$smtp->quit or
die "erreur de fermeture de connexion au serveur SMTP";
#--- code end ---
--
Rudi Bruchez
Consultant indépendant
modélisation, administration, optimisation,
Solutions MS SQL Server et informatique libre.
MCDBA, SCJP2
http://www.babaluga.com/
Brigitte a écrit:
> l'utilisation des lib perl d'envoi de mail est incompatible avec SQL DMO.
> Le script reste bloqué.
> Le comportement est le meme pour ces 2 lib :
> - SendMail
> - Net::SMTP
Bonjour,
Il n'y a pas d'incompatibilité entre le DMO et des librairies Perl. SQL-DMO
est une suite d'objets COM, et n'a pas d'incidence sur la façon dont les
libraires Perl fonctionnent.
Ci-dessous un code d'exemple, testé avec ActivePerl 5.8.7, qui ne pose pas
de problème chez moi.
#--- code start ---
use strict;
use Win32::OLE 'in';
use Win32::OLE::Const 'Microsoft SQLDMO';
use Net::SMTP;
my $serverName = 'myServer';
my $SMTPServer = 'smtp.myserver.com';
my $recipients = [ 'Brigitte@discussions.microsoft.com' ];
my $sender = 'Brigitte@discussions.microsoft.com';
my $sub = 'test mail DMO';
my ($to, $from) = ('Brigitte@discussions.microsoft.com',
'Brigitte@discussions.microsoft.com' );
my $msg;
my @confs = ();
my $server = Win32::OLE->new('SQLDMO.SQLServer2')
or die "erreur de creation de l'objet SQLDMO";
my $smtp = Net::SMTP->new($SMTPServer)
or die "erreur de connexion au serveur SMTP $SMTPServer.";
$server->{LoginSecure} = 1;
$server->{LoginTimeout} = 30;
$server->connect($serverName);
! Win32::OLE->LastError() or
die "erreur de connexion a $serverName.";
foreach my $conf (in($server->Configuration->ConfigValues())) {
push @confs, $conf->{name};
}
$server->DisConnect();
$msg = join "n", @confs;
$smtp->mail($sender);
$smtp->to(@$recipients);
$smtp->data();
$smtp->datasend("Subject: $subn");
$smtp->datasend("To: $ton");
$smtp->datasend("From: $fromn");
$smtp->datasend("n");
$smtp->datasend("$msgn");
$smtp->datasend() or
die "erreur d'envoi au serveur SMTP";
$smtp->quit or
die "erreur de fermeture de connexion au serveur SMTP";
#--- code end ---
--
Rudi Bruchez
Consultant indépendant
modélisation, administration, optimisation,
Solutions MS SQL Server et informatique libre.
MCDBA, SCJP2
http://www.babaluga.com/
Brigitte a écrit:
> l'utilisation des lib perl d'envoi de mail est incompatible avec SQL DMO.
> Le script reste bloqué.
> Le comportement est le meme pour ces 2 lib :
> - SendMail
> - Net::SMTP
Bonjour,
Il n'y a pas d'incompatibilité entre le DMO et des librairies Perl. SQL-DMO
est une suite d'objets COM, et n'a pas d'incidence sur la façon dont les
libraires Perl fonctionnent.
Ci-dessous un code d'exemple, testé avec ActivePerl 5.8.7, qui ne pose pas
de problème chez moi.
#--- code start ---
use strict;
use Win32::OLE 'in';
use Win32::OLE::Const 'Microsoft SQLDMO';
use Net::SMTP;
my $serverName = 'myServer';
my $SMTPServer = 'smtp.myserver.com';
my $recipients = [ '' ];
my $sender = '';
my $sub = 'test mail DMO';
my ($to, $from) = ('',
'' );
my $msg;
my @confs = ();
my $server = Win32::OLE->new('SQLDMO.SQLServer2')
or die "erreur de creation de l'objet SQLDMO";
my $smtp = Net::SMTP->new($SMTPServer)
or die "erreur de connexion au serveur SMTP $SMTPServer.";
$server->{LoginSecure} = 1;
$server->{LoginTimeout} = 30;
$server->connect($serverName);
! Win32::OLE->LastError() or
die "erreur de connexion a $serverName.";
foreach my $conf (in($server->Configuration->ConfigValues())) {
push @confs, $conf->{name};
}
$server->DisConnect();
$msg = join "n", @confs;
$smtp->mail($sender);
$smtp->to(@$recipients);
$smtp->data();
$smtp->datasend("Subject: $subn");
$smtp->datasend("To: $ton");
$smtp->datasend("From: $fromn");
$smtp->datasend("n");
$smtp->datasend("$msgn");
$smtp->datasend() or
die "erreur d'envoi au serveur SMTP";
$smtp->quit or
die "erreur de fermeture de connexion au serveur SMTP";
#--- code end ---
--
Rudi Bruchez
Consultant indépendant
modélisation, administration, optimisation,
Solutions MS SQL Server et informatique libre.
MCDBA, SCJP2
http://www.babaluga.com/
J'ai adapté votre script de la sorte ( visible ci-dessous ). Si la machine
SQLD01 qui héberge le SQL Server est stoppé, le script est bloqué
indéfiniement sur la commande connect et ne rend jamais la main
J'ai adapté votre script de la sorte ( visible ci-dessous ). Si la machine
SQLD01 qui héberge le SQL Server est stoppé, le script est bloqué
indéfiniement sur la commande connect et ne rend jamais la main
J'ai adapté votre script de la sorte ( visible ci-dessous ). Si la machine
SQLD01 qui héberge le SQL Server est stoppé, le script est bloqué
indéfiniement sur la commande connect et ne rend jamais la main
Brigitte a écrit:
> J'ai adapté votre script de la sorte ( visible ci-dessous ). Si la machine
> SQLD01 qui héberge le SQL Server est stoppé, le script est bloqué
> indéfiniement sur la commande connect et ne rend jamais la main
Intéressant. Et que se passe-t-il si vous créez l'objet SMTP après
l'ouverture de la connexion à SQL-DMO ?
QQch comme ceci :
# --------- extrait du code ----------
$server->connect($serverName);
if ( Win32::OLE->LastError() )
{
print "erreur de connexion a $serverName. Win32::OLE::LastError()" .
Win32::FormatMessage( Win32::OLE::LastError() );
}
my $smtp = Net::SMTP->new($SMTPServer)
or die "erreur de connexion au serveur SMTP $SMTPServer.";
# ------------------------------------
--
Rudi Bruchez
Consultant indépendant
modélisation, administration, optimisation,
Solutions MS SQL Server et informatique libre.
MCDBA, SCJP2
http://www.babaluga.com/
Brigitte a écrit:
> J'ai adapté votre script de la sorte ( visible ci-dessous ). Si la machine
> SQLD01 qui héberge le SQL Server est stoppé, le script est bloqué
> indéfiniement sur la commande connect et ne rend jamais la main
Intéressant. Et que se passe-t-il si vous créez l'objet SMTP après
l'ouverture de la connexion à SQL-DMO ?
QQch comme ceci :
# --------- extrait du code ----------
$server->connect($serverName);
if ( Win32::OLE->LastError() )
{
print "erreur de connexion a $serverName. Win32::OLE::LastError()" .
Win32::FormatMessage( Win32::OLE::LastError() );
}
my $smtp = Net::SMTP->new($SMTPServer)
or die "erreur de connexion au serveur SMTP $SMTPServer.";
# ------------------------------------
--
Rudi Bruchez
Consultant indépendant
modélisation, administration, optimisation,
Solutions MS SQL Server et informatique libre.
MCDBA, SCJP2
http://www.babaluga.com/
Brigitte a écrit:
> J'ai adapté votre script de la sorte ( visible ci-dessous ). Si la machine
> SQLD01 qui héberge le SQL Server est stoppé, le script est bloqué
> indéfiniement sur la commande connect et ne rend jamais la main
Intéressant. Et que se passe-t-il si vous créez l'objet SMTP après
l'ouverture de la connexion à SQL-DMO ?
QQch comme ceci :
# --------- extrait du code ----------
$server->connect($serverName);
if ( Win32::OLE->LastError() )
{
print "erreur de connexion a $serverName. Win32::OLE::LastError()" .
Win32::FormatMessage( Win32::OLE::LastError() );
}
my $smtp = Net::SMTP->new($SMTPServer)
or die "erreur de connexion au serveur SMTP $SMTPServer.";
# ------------------------------------
--
Rudi Bruchez
Consultant indépendant
modélisation, administration, optimisation,
Solutions MS SQL Server et informatique libre.
MCDBA, SCJP2
http://www.babaluga.com/
Conclusion il suffit de faire un new sur Net::SMTP pour bloquer les appel de
connexion SQL DMO sur machine stoppée
Conclusion il suffit de faire un new sur Net::SMTP pour bloquer les appel de
connexion SQL DMO sur machine stoppée
Conclusion il suffit de faire un new sur Net::SMTP pour bloquer les appel de
connexion SQL DMO sur machine stoppée
Brigitte a écrit:
> Conclusion il suffit de faire un new sur Net::SMTP pour bloquer les appel de
> connexion SQL DMO sur machine stoppée
Bonjour,
Donc si je comprends bien, pour régler (de manière insatisfaisante, mais
bon) ton problème, tu dois éviter dans ton code d'ouvrir une connexion DMO
lorsqu'une instance de Net::SMTP est créé. Si par exemple dans :
Scénario 1
use Net::SMTP
Connexion DMO OK
Envoi de mail
Seconde Connexion DMO NOK !!
Tu fais :
Scénario 1
use Net::SMTP
Connexion DMO OK
Envoi de mail
$smtp->quit(); # ou undef($smtp)
Seconde Connexion DMO ???
Qu'est-ce que ça donne ?
Une possibilité est qu'il se passe quelque chose au niveau de la connexion
réseau, qui empêche Perl ou le DMO de recevoir une notification
d'impossibilité de connexion. Est-ce que le serveur SMTP est sur la même
machine que le serveur SQL ?
Il serait peut-être intéressant de regarder ce qui se passe au niveau de la
couche TCP, sur les ports TCP 1433, 25 (SMTP), et udp 1434, par exemple
avec TDIMon http://www.sysinternals.com/Utilities/TdiMon.html ou Ethereal.
J'ai vu dans ton code que tu te connectes à une instance nommée. Pour
obtenir cette instance nommée, il y a aussi une communication avec le port
UDP 1434 sur le serveur (il y a un listener service qui retourne les infos
d'instance nommée sur ce port), donc ceci joue peut-être également. Qu'en
est-il d'une instance par défaut ?
A propos, as-tu plus d'informations si tu exécutes ton script avec perl -W
?
--
Rudi Bruchez
Consultant indépendant
modélisation, administration, optimisation,
Solutions MS SQL Server et informatique libre.
MCDBA, SCJP2
http://www.babaluga.com/
Brigitte a écrit:
> Conclusion il suffit de faire un new sur Net::SMTP pour bloquer les appel de
> connexion SQL DMO sur machine stoppée
Bonjour,
Donc si je comprends bien, pour régler (de manière insatisfaisante, mais
bon) ton problème, tu dois éviter dans ton code d'ouvrir une connexion DMO
lorsqu'une instance de Net::SMTP est créé. Si par exemple dans :
Scénario 1
use Net::SMTP
Connexion DMO OK
Envoi de mail
Seconde Connexion DMO NOK !!
Tu fais :
Scénario 1
use Net::SMTP
Connexion DMO OK
Envoi de mail
$smtp->quit(); # ou undef($smtp)
Seconde Connexion DMO ???
Qu'est-ce que ça donne ?
Une possibilité est qu'il se passe quelque chose au niveau de la connexion
réseau, qui empêche Perl ou le DMO de recevoir une notification
d'impossibilité de connexion. Est-ce que le serveur SMTP est sur la même
machine que le serveur SQL ?
Il serait peut-être intéressant de regarder ce qui se passe au niveau de la
couche TCP, sur les ports TCP 1433, 25 (SMTP), et udp 1434, par exemple
avec TDIMon http://www.sysinternals.com/Utilities/TdiMon.html ou Ethereal.
J'ai vu dans ton code que tu te connectes à une instance nommée. Pour
obtenir cette instance nommée, il y a aussi une communication avec le port
UDP 1434 sur le serveur (il y a un listener service qui retourne les infos
d'instance nommée sur ce port), donc ceci joue peut-être également. Qu'en
est-il d'une instance par défaut ?
A propos, as-tu plus d'informations si tu exécutes ton script avec perl -W
?
--
Rudi Bruchez
Consultant indépendant
modélisation, administration, optimisation,
Solutions MS SQL Server et informatique libre.
MCDBA, SCJP2
http://www.babaluga.com/
Brigitte a écrit:
> Conclusion il suffit de faire un new sur Net::SMTP pour bloquer les appel de
> connexion SQL DMO sur machine stoppée
Bonjour,
Donc si je comprends bien, pour régler (de manière insatisfaisante, mais
bon) ton problème, tu dois éviter dans ton code d'ouvrir une connexion DMO
lorsqu'une instance de Net::SMTP est créé. Si par exemple dans :
Scénario 1
use Net::SMTP
Connexion DMO OK
Envoi de mail
Seconde Connexion DMO NOK !!
Tu fais :
Scénario 1
use Net::SMTP
Connexion DMO OK
Envoi de mail
$smtp->quit(); # ou undef($smtp)
Seconde Connexion DMO ???
Qu'est-ce que ça donne ?
Une possibilité est qu'il se passe quelque chose au niveau de la connexion
réseau, qui empêche Perl ou le DMO de recevoir une notification
d'impossibilité de connexion. Est-ce que le serveur SMTP est sur la même
machine que le serveur SQL ?
Il serait peut-être intéressant de regarder ce qui se passe au niveau de la
couche TCP, sur les ports TCP 1433, 25 (SMTP), et udp 1434, par exemple
avec TDIMon http://www.sysinternals.com/Utilities/TdiMon.html ou Ethereal.
J'ai vu dans ton code que tu te connectes à une instance nommée. Pour
obtenir cette instance nommée, il y a aussi une communication avec le port
UDP 1434 sur le serveur (il y a un listener service qui retourne les infos
d'instance nommée sur ce port), donc ceci joue peut-être également. Qu'en
est-il d'une instance par défaut ?
A propos, as-tu plus d'informations si tu exécutes ton script avec perl -W
?
--
Rudi Bruchez
Consultant indépendant
modélisation, administration, optimisation,
Solutions MS SQL Server et informatique libre.
MCDBA, SCJP2
http://www.babaluga.com/
1) Il est vrai que le problème ne se produit pas pour les instances par défaut
2) Toute tentative de connexion DMO sur machine stoppée est bloquée meme si
je fais un quit apres l'envoi d'un mail.
3) En fait il suffit que je fasse appel à l'instruction
Net::SMTP->new($SMTPServer) pour bloquer toute tentative de connexion
ultérieure sur machine stoppée. Je ne connais pas d'API du type delete sur
l'objet SMTP
4) Les traces TDI montrent que ca bloque effectivememnt sur le port UDP 1434
1) Il est vrai que le problème ne se produit pas pour les instances par défaut
2) Toute tentative de connexion DMO sur machine stoppée est bloquée meme si
je fais un quit apres l'envoi d'un mail.
3) En fait il suffit que je fasse appel à l'instruction
Net::SMTP->new($SMTPServer) pour bloquer toute tentative de connexion
ultérieure sur machine stoppée. Je ne connais pas d'API du type delete sur
l'objet SMTP
4) Les traces TDI montrent que ca bloque effectivememnt sur le port UDP 1434
1) Il est vrai que le problème ne se produit pas pour les instances par défaut
2) Toute tentative de connexion DMO sur machine stoppée est bloquée meme si
je fais un quit apres l'envoi d'un mail.
3) En fait il suffit que je fasse appel à l'instruction
Net::SMTP->new($SMTPServer) pour bloquer toute tentative de connexion
ultérieure sur machine stoppée. Je ne connais pas d'API du type delete sur
l'objet SMTP
4) Les traces TDI montrent que ca bloque effectivememnt sur le port UDP 1434
Brigitte a écrit:
> 1) Il est vrai que le problème ne se produit pas pour les instances par défaut
>
> 2) Toute tentative de connexion DMO sur machine stoppée est bloquée meme si
> je fais un quit apres l'envoi d'un mail.
>
> 3) En fait il suffit que je fasse appel à l'instruction
> Net::SMTP->new($SMTPServer) pour bloquer toute tentative de connexion
> ultérieure sur machine stoppée. Je ne connais pas d'API du type delete sur
> l'objet SMTP
>
> 4) Les traces TDI montrent que ca bloque effectivememnt sur le port UDP 1434
Bonjour,
Il n'y a effectivement pas de destruction explicite d'objet en Perl. Il y a
un garbage collector qui nettoie les objets qui ne sont plus référencés,
mais il n'y a pas de garantie que cela se fasse à un moment ou à un autre,
c'est pour cela que je vous proposais de faire un undef ($smtp) pour
supprimer la référence.
Peut-être une des premières suggestions que j'aurais dû faire est :
avez-vous installé la dernière version du MDAC ? Cela peut aider. Et quel
est le service pack appliqué sur le serveur SQL ? Il y a eu quelques
changements au niveau de la connectivité, entre les service packs.
Vous avez peut-être aussi une solution simple pour régler le problème : ce
que fait le DMO dans votre cas, est d'envoyer une demande en UPD 1434 au
listener du serveur SQL. Ce service sert à communiquer au client quel est
le port TCP attribué dynamiquement à l'instance nommée de SQL Server.
Vous pouvez contourner ce fonctionnement en attribuant un port fixe à
l'instance SQL, et en créant sur le client un alias (dans Client Network
Utility) pour le référencer avec le port. Après, essayez de vous connecter
avec l'alias.
Selon la trace de TDIMon, c'est comme si le DMO perd la réponse du serveur,
ou ne crée pas de TDI_SET_EVENT_HANDLER pour recevoir la réponse, ou... ça
peut être plusieurs choses. Si c'est pour creuser plus loin, il pourrait
être utile de faire la même chose du côté du serveur pour voir ce qu'il
reçoit et ce qu'il envoie.
Bon courage
--
Rudi Bruchez
Consultant indépendant
modélisation, administration, optimisation,
Solutions MS SQL Server et informatique libre.
MCDBA, SCJP2
http://www.babaluga.com/
Brigitte a écrit:
> 1) Il est vrai que le problème ne se produit pas pour les instances par défaut
>
> 2) Toute tentative de connexion DMO sur machine stoppée est bloquée meme si
> je fais un quit apres l'envoi d'un mail.
>
> 3) En fait il suffit que je fasse appel à l'instruction
> Net::SMTP->new($SMTPServer) pour bloquer toute tentative de connexion
> ultérieure sur machine stoppée. Je ne connais pas d'API du type delete sur
> l'objet SMTP
>
> 4) Les traces TDI montrent que ca bloque effectivememnt sur le port UDP 1434
Bonjour,
Il n'y a effectivement pas de destruction explicite d'objet en Perl. Il y a
un garbage collector qui nettoie les objets qui ne sont plus référencés,
mais il n'y a pas de garantie que cela se fasse à un moment ou à un autre,
c'est pour cela que je vous proposais de faire un undef ($smtp) pour
supprimer la référence.
Peut-être une des premières suggestions que j'aurais dû faire est :
avez-vous installé la dernière version du MDAC ? Cela peut aider. Et quel
est le service pack appliqué sur le serveur SQL ? Il y a eu quelques
changements au niveau de la connectivité, entre les service packs.
Vous avez peut-être aussi une solution simple pour régler le problème : ce
que fait le DMO dans votre cas, est d'envoyer une demande en UPD 1434 au
listener du serveur SQL. Ce service sert à communiquer au client quel est
le port TCP attribué dynamiquement à l'instance nommée de SQL Server.
Vous pouvez contourner ce fonctionnement en attribuant un port fixe à
l'instance SQL, et en créant sur le client un alias (dans Client Network
Utility) pour le référencer avec le port. Après, essayez de vous connecter
avec l'alias.
Selon la trace de TDIMon, c'est comme si le DMO perd la réponse du serveur,
ou ne crée pas de TDI_SET_EVENT_HANDLER pour recevoir la réponse, ou... ça
peut être plusieurs choses. Si c'est pour creuser plus loin, il pourrait
être utile de faire la même chose du côté du serveur pour voir ce qu'il
reçoit et ce qu'il envoie.
Bon courage
--
Rudi Bruchez
Consultant indépendant
modélisation, administration, optimisation,
Solutions MS SQL Server et informatique libre.
MCDBA, SCJP2
http://www.babaluga.com/
Brigitte a écrit:
> 1) Il est vrai que le problème ne se produit pas pour les instances par défaut
>
> 2) Toute tentative de connexion DMO sur machine stoppée est bloquée meme si
> je fais un quit apres l'envoi d'un mail.
>
> 3) En fait il suffit que je fasse appel à l'instruction
> Net::SMTP->new($SMTPServer) pour bloquer toute tentative de connexion
> ultérieure sur machine stoppée. Je ne connais pas d'API du type delete sur
> l'objet SMTP
>
> 4) Les traces TDI montrent que ca bloque effectivememnt sur le port UDP 1434
Bonjour,
Il n'y a effectivement pas de destruction explicite d'objet en Perl. Il y a
un garbage collector qui nettoie les objets qui ne sont plus référencés,
mais il n'y a pas de garantie que cela se fasse à un moment ou à un autre,
c'est pour cela que je vous proposais de faire un undef ($smtp) pour
supprimer la référence.
Peut-être une des premières suggestions que j'aurais dû faire est :
avez-vous installé la dernière version du MDAC ? Cela peut aider. Et quel
est le service pack appliqué sur le serveur SQL ? Il y a eu quelques
changements au niveau de la connectivité, entre les service packs.
Vous avez peut-être aussi une solution simple pour régler le problème : ce
que fait le DMO dans votre cas, est d'envoyer une demande en UPD 1434 au
listener du serveur SQL. Ce service sert à communiquer au client quel est
le port TCP attribué dynamiquement à l'instance nommée de SQL Server.
Vous pouvez contourner ce fonctionnement en attribuant un port fixe à
l'instance SQL, et en créant sur le client un alias (dans Client Network
Utility) pour le référencer avec le port. Après, essayez de vous connecter
avec l'alias.
Selon la trace de TDIMon, c'est comme si le DMO perd la réponse du serveur,
ou ne crée pas de TDI_SET_EVENT_HANDLER pour recevoir la réponse, ou... ça
peut être plusieurs choses. Si c'est pour creuser plus loin, il pourrait
être utile de faire la même chose du côté du serveur pour voir ce qu'il
reçoit et ce qu'il envoie.
Bon courage
--
Rudi Bruchez
Consultant indépendant
modélisation, administration, optimisation,
Solutions MS SQL Server et informatique libre.
MCDBA, SCJP2
http://www.babaluga.com/
Peut-on explictement spécifier le port à la connexion en isql ou DMO?
Peut-on explictement spécifier le port à la connexion en isql ou DMO?
Peut-on explictement spécifier le port à la connexion en isql ou DMO?
Brigitte a écrit:
> Peut-on explictement spécifier le port à la connexion en isql ou DMO?
Bonjour,
Il y a pour les chaînes de connexion une façon (non documentée à ma
connaissance) de faire, qui est "Data Source=ServerName,port"
Essayez peut-être de faire ceci :
my $serverName = 'sqld01,port';
Mais je ne sais absolument pas si ça va marcher.
--
Rudi Bruchez
Consultant indépendant
modélisation, administration, optimisation,
Solutions MS SQL Server et informatique libre.
MCDBA, SCJP2
http://www.babaluga.com/
Brigitte a écrit:
> Peut-on explictement spécifier le port à la connexion en isql ou DMO?
Bonjour,
Il y a pour les chaînes de connexion une façon (non documentée à ma
connaissance) de faire, qui est "Data Source=ServerName,port"
Essayez peut-être de faire ceci :
my $serverName = 'sqld01,port';
Mais je ne sais absolument pas si ça va marcher.
--
Rudi Bruchez
Consultant indépendant
modélisation, administration, optimisation,
Solutions MS SQL Server et informatique libre.
MCDBA, SCJP2
http://www.babaluga.com/
Brigitte a écrit:
> Peut-on explictement spécifier le port à la connexion en isql ou DMO?
Bonjour,
Il y a pour les chaînes de connexion une façon (non documentée à ma
connaissance) de faire, qui est "Data Source=ServerName,port"
Essayez peut-être de faire ceci :
my $serverName = 'sqld01,port';
Mais je ne sais absolument pas si ça va marcher.
--
Rudi Bruchez
Consultant indépendant
modélisation, administration, optimisation,
Solutions MS SQL Server et informatique libre.
MCDBA, SCJP2
http://www.babaluga.com/