Discussion :

[Depite]

Bonjour,

La politique de licences de Microsoft est toujours très compliquée:

Je viens d'installer SQL server 2008 R2 Workgroup sur un serveur Microsoft Windows 2008.

J'ai fait l'acquisition de 7 licences suplémentaires ce qui doit porter à 12 le nombre total de connexions simultanées autorisées sur le serveur SQL.
Au cours de l'installation, via l'assistant, je n'ai remarqué aucune information quant aux licences.
Je ne trouve nulle part ces informations ni le moyen d'en déclarer d'autres.

Les différentes recherches que je n'ai pas manqué de lancer sur internet ne donnent rien. Comment avez-vous fait tous pour enregistrer vos licences ?
Quelqu'un peut-il m'éclairer sur ce mystère ?

[Ptit_Dje]

De temps a autre, Microsoft demande de faire un inventaire de ce qui est installe sur les serveurs.
Il est bien de garder une liste avec la version installee, le nbr de licenses ... histoire de pouvoir leur prouver que tout est en ordre.

[Depite]

Bonjour et merci "Pti dje" pour ta réponse qui correspond bien à ce que j'avais compris d'un point de vu administratif et commercial.

Mais mon problème est plus élémentaire et concret :
J'ai acheté et installé SQL 2008 R2 WorkGroup (5 licences) plus 7 licences utilisateurs supplémentaires ce qui porte à 12 le nombre de connexions commercialement autorisées (j'ai 12 PC clients).
Dès lors que 5 utilisateurs différents son connectés je ne plus en connecter un nouveau, comme si le système était limité à 5 utilisateurs!

Donc: y a-t-il quelque chose à déclarer au niveau du serveur pour permettre les connexions déclarées ?

Un bémol :
J'accède au serveur essentiellement à travers une application interne développée sous Access 2010 et déployée avec le runtime 2010. L'échec de connexion est déclaré au lancement par la biliothèque OLEDB. J'ai appliqué les mises à jour du runtime en SP1 et, par acquis de conscience de SQLCLI 10.

Hors la connexion n'est pas rejettée si je crée ou utilise une connexion ODBC à travers Excel par exemple.

J'insiste en répétant que si je déconnecte les postes initialement connectés, je peux connecter les nouveaux postes...

J'ai essayé la suggestion de Microsoft consistant à remplacer le nom du serveur par son adresse TCP/IP dans la chaine de connexion

source=tcp:192.168.1.1,1433

C'est pareil.

[dbaffaleuf]

- Est-ce que tu peux ouvrir 12 connexions avec SQLCMD ?
- Quel est le message d'erreur ?

[Depite]

Bonjour dbaffaleuf, et merci pour ta réponse rapide.

1. Lorsque l'activité commerciale a fait une pause j'ai fermé l'application Access sur 1 PC et réessayé d'en lancer un qui ne démarrait pas (pour vérifier) : il a connecté tout de suite; j'ai essayé avec le second = pareil, le 3ième pareil... au total 9 PC connectés sans erreur !
2. Je laisse mes 9 PC connectés et je fais ce que tu me propose en ouvrant autant de fenêtre "DOS" sur mon PC et en y démarrant SQLCMD avec le login SA : tout connecte, je n'ai pas de message d'erreur.

Bon, tant mieux, oui mais...attendu que je n'ai apporté aucune modification à quoi que ce soit, le problème initial reste inexpliqué et risque donc de se reproduire à un moment stratégiquement plus sensible et urgent.

Alors, si ça ne vient pas d'un rejet du serveur, j'imagine que ça peut venir d'un échec de localisation du serveur par le client OLEDB lié soit à une défaillance du réseau - ce qui semble peu probable attendu que j'accède aux volumes partagés et qu'une connexion ODBC aboutit, soit à un problème au niveau TCP/IP, malgré l'utilisation de la connexion explicite "source=tcp:XXX.XXX.X.X"

Dans quelle direction chercher ?

[dbaffaleuf]

Dès lors que 5 utilisateurs différents son connectés je ne plus en connecter un nouveau, comme si le système était limité à 5 utilisateurs!

A cette étape-là, quel est le message d'erreur (à la 6ième connexion) ?