Discussion :

[info3licen]

Toujours la même erreur...

Merci beaucoup Népomucène Merci pour tout ce que t'a fait pour moi, je suis vraiment désolé pour le dérangement que je vous ai apporté.

PS: d'après l'erreur, je pense que c'est une erreur très fréquente puisque j'ai trouvée beaucoup de poste parlant de ça! j'ai vue les solutions mais c'est des solutions pour SQL2005 ils leurs montre comment faire la configuration sur SQL2005. Donc je dois chercher la configuration de SQL2000...

Merci pour votre amabilité

[Népomucène]

Il faut aussi jeter un coup d’œil dans Enterprise manager,
faire un clic-droit sur le serveur LOCAL
aller dans les propriétés du serveur
onglet sécurité
-> vérifier que l’authentification est bien sur [SQL Server ET Windows]
et non pas uniquement Windows

[info3licen]

Ah Ouii c'est vrai elle marche bien mais uniquement sur Analyseur de requête c'est a dire après avoir fait ce que tu ma proposé maintenant j'ai pue accédé a Analyseur de requête avec l'utilisateur 'sa'

Mais avec eclipse Non la même erreur aussi !

Thank's

[Népomucène]

A force de gratter tu vas finir par trouver.
Fais un "post" dans le forum SQL Server.
Quelqu'un a peut-être eu le cas.

[info3licen]

Mille Merci

[Laurent.B]

Bonjour,

J'apporte juste une précision de manière à écarter l'implication d'Eclipse.

Quand tu exécutes ton programme Java, Eclipse n'intervient pas dans la connexion que ton programme va tenter d'établir avec la base (du moment que le driver est bien présent dans le classpath à l'exécution).

Pour vérifier cela, il suffit d'exécuter ton application directement en ligne de commande. Le résultat devrait être strictement identique.

D'autre part, lorsque tu as le message

echec de la connexion TCP/IP à l'hôte localhost, port 1433. Erreur : "Connection refused: connect. Vérifier les propriétés de connexion, assurez-vous qu'une instance de SQL Server est en cour d'exécution sur l'hôte et accepte les connexion TCP/IP au port, et vérifier qu'un pare-feu ne bloque les connexions TCP au port."

C'est que c'est le cas, soit le port n'est pas le bon, soit le serveur n'est pas démarré. Quand ton serveur de BDD est sur la même machine, il est peu probable que l'accès soit refusé, en dehors du pare-feu que tu as déjà désactivé (et qui doit l'être avant de démarrer le serveur, ou qu'une règle autorise le pare-feu à laisser le serveur BDD à prendre le port qu'il demande).

Pour vérifier que ton serveur est actif, fait un netstat -anb en ligne de commande ou utilise TcpView (plus convivial).
Bon, si tu parviens à accéder à ton serveur via l'outil d'admin, a priori c'est qu'il doit être actif...

[info3licen]

Bonjour Merci pour votre réponse.

Pour le port, j'ai vérifier dans utilitaire serveur réseau SqlServer et le port est de : 1433, le serveur est démarré aussi.

Pour vérifier que ton serveur est actif, fait un netstat -anb en ligne de commande ou utilise TcpView (plus convivial).

j'ai vérifier avec netstat -anb: Et il y a aucun programme qui écoute sur 1433 c'est a dire aucun programme utilise ce port!!!

...

[Népomucène]

Fait une petite application qui teste la connexion
et mets-la dans un jar
Lances - la en dehors d'éclipse pour vérifier "au cas où"
A vrai dire, je n'y croit pas mais bon ...