[D10 Seattle][SQL Server] L'autorisation SELECT a été refusée

Bonjour le forum

Je vous explique ma problématique ...

J'ai développé un programme Delphi se connectant en ODBC sur une base de données SQL Server. La BDD que j'utilise est issue du backup de la BDD de mon client.
Sur ma machine, l'application est fonctionnelle. Sur la machine de mon client, l'application déclenche le message d'erreur "[FireDAC][Phys][ODBC][Microsoft][ODBC SQL Server Driver][SQL Server] L'autorisation SELECT a été refusée sur l'objet 'NOM_DE_LA_TABLE', base de données 'NOM_DE_LA_BDD', schéma 'dbo'." sur une des tables. D'autres tables ne posent pas de problème.

Une autre application Delphi développée par le client lui-même, avec une version de Delphi beaucoup plus ancienne, peut se connecter sans problème sur la table en question.

Les deux applications utilisent la même connexion ODBC.

En résumé :
- 1 connexion ODBC
- 2 applications installées sur une même machine essaient d'accéder à une table d'une base de données SQL Server
- 1 application requête la table sans problème
- 1 application déclenche l'erreur lorsqu'elle requête la table

Quelqu'un a une idée ?
Est-ce que ce problème peut venir du paramétrage des querys que j'utilise ?
Ou plutôt est-ce que tu paramétrage sur les querys pourrait empêcher l'erreur ?

Toute aide sera la bienvenue et d'avance je vous en remercie !!!

Fred

Bonjour,

Je ne connais pas MySQL Server mais j'ai eu une expérience similaire avec FireBird. La cause en était que la base de données était en mode mono-utilisateur c'est-à-dire qu'un seul client pouvait accéder à la BDD.
Si je cherche dans la documentation SQL Server je lis :

Citation:

---

-mClient Application Name Limite les connexions à une application cliente spécifiée. Par exemple, -mSQLCMD limite les connexions à une seule connexion et cette connexion doit s'identifier en tant que programme client SQLCMD. Utilisez cette option lorsque vous démarrez SQL Server en mode mono-utilisateur et qu'une application cliente inconnue prend la seule connexion disponible. Utilisez 'Microsoft SQL Server Management Studio - Query' pour vous connecter à l'éditeur de requête SSMS. L'option SSMS Query Editor ne peut pas être configurée à l'aide du gestionnaire de configuration SQL Server car elle inclut le caractère tiret qui est rejeté par l'outil.

Le nom de l'application client est sensible à la casse. Des guillemets doubles sont requis si le nom de l'application contient des espaces ou des caractères spéciaux.

Exemples
C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Binn\sqlservr -s MSSQLSERVER -m"Microsoft SQL Server Management Studio - Query"

C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Binn\sqlservr -s MSSQLSERVER -mSQLCMD

---

Il semblerait qu'il y ait aussi des instructions SQL pour le faire (ce qui est certainement plus simple :mouarf:)

tentez un

Code:

---

ALTER DATABASE MABASE SET MULTI_USER;

---

pour moi ce n'est donc pas un problème Delphi ni ODBC (bien que je ne soit pas un fan d'ODBC) mais plutôt SQL Server donc pour plus de renseignements le forum ad hoc

Bonjour Sergio et merci pour la réponse !

Le paramétrage dont tu parles pourrait induire un comportement comme ça ?
Des tables sur lesquelles on peut requêter et d'autres sur lesquelles on peut pas ?

Je vais jeter un œil au forum SQL Server

Bonne journée

Fred

Citation:

---

Envoyé par Mirande

Le paramétrage dont tu parles pourrait induire un comportement comme ça ?

---

Sur la base de données, oui. Simple à vérifier en lançant deux programmes utilisant la BDD sur le même poste le second programme n'aura pas d'accès

Citation:

---

Envoyé par Mirande

Des tables sur lesquelles on peut requêter et d'autres sur lesquelles on ne peut pas ?

---

ça c'est des questions de rôles mais, comme déjà écrit je ne peut faire que des comparaisons avec le SGBD que j'utilise le plus (Firebird)

J'ai dû mal m'exprimer dans mon premier post ...
Les deux programmes dont je parles ne sont pas lancés en même temps !
Il s'agit de deux programmes que l'on fait tourner sur la même machine mais ils sont testés à tour de rôle.

Alors ce serait une question de ROLE et d'AUTHORIZATION ?
https://learn.microsoft.com/fr-fr/sq...l-server-ver16

Sans compter que le schéma dbo n'est pas fait pour être le schéma des données, il faut créer un schéma dédié, éventuellement passer le login en dbowner du schéma dédié

Tu as penser à remapper correctement les utilisateurs importés avec les logins ? un coup de sp_change_users_login ... je bosse en SQL Server mais j'ai toujours un peu de mal avec le bon enchainement d'un Restore, Create login puis la synchro user.

Ne pas oublier les problèmes de droits de chaque user pouvant être différent dans différents schéma mais associé au même login :aie:
Tu peux avoir un user A dans la DB1\Schema1 en full access tout étant limité dans la DB2\Schema1 ...

Dans Microsoft SQL Server Management Studio, as-tu essayé tes logins et tes accès avant même de le faire en Delphi
As-tu vérifié tes Securables et Permissions
https://i.stack.imgur.com/k0Kiq.png

Bonjour Shai

Je peux pas toucher à la config SQL Server.
La base de données en question est liée à un logiciel métier d'un gros éditeur.
L'application que je développe vient en complément de ce logiciel métier.

Pour des raisons de responsabilité par rapport à cet éditeur, je ne voudrais pas que mon client ai des soucis de maintenance par la suite.

Mauvaise pratique alors !

Le logiciel métier devrait te proposer un Service REST pour le manipuler, rien qu'avoir les logins et mot de passe de la DB pour ton compte, ce n'est pas terrible !
Aucune surprise que les accès même en lecture ne soit pas autorisée à n'importe quel utilisateur, encore plus pour une base de PROD non-anonymisé !



En si c'est un ancien Delphi pour l'autre logiciel, ODBC est-il vraiment le même ?
32Bits vs 64Bits
C:\Windows\SysWOW64\odbcad32.exe vs C:\Windows\System32\odbcad32.exe

Les accès en lecture ne posent aucun problème sur certaines tables.
Pour infos, les développements sont faits en accord avec l'éditeur.
Les développements m'ont été confiés parce que l'éditeur n'avait pas le temps (ou pas envie ...) de le faire.

D'autres points de la base de données posent aussi pas mal de questions.
Par exemple, il n'y a aucune contrainte d'intégrité et même les champs "clé" ne représentent pas forcément toujours la même information dans des tables différentes.

Tout ça c'est clairement un projet qui va droit dans le mur !

Faut déjà que tes SQL fonctionne dans Microsoft SQL Server Management Studio avant d'aller plus loin, oublie Delphi tant que l'outil SQL officiel n'accède pas aux données avec le bon login\schéma

Et je confirme qu'il faut vérifier les permissions avant d'avancer, ne pas faire cela à l'aveugle, il y a une bonne raison d'avoir un message de refus !

Aucun soucis dans Microsoft SQL Server Management Studio.
La requête qui est rejetée est un simple SELECT *.
Sur ma machine de dév ou j'ai remonté un backup de la base client, je n'ai pas de soucis.
Une autre appli, développée il y a plusieurs années avec BDS2006, peut requêter sur la table en question sans problème.
Je me demande si ça ne viendrait pas des composants firedac delphi.
Je vais essayer de me connecter avec d'autres composants, genre dbexpress.

C'est curieux de ne même pas songer à ADO \ OLEDB de Microsoft et de tenter les Provider de Delphi qui utilisent finalement OLEDB via ODBC soit Driver{ODBC Driver 17 for SQL Server} ... si cela utilise un driver natif directement, je comprendrais mais repasser par ODBC ça n'apporte plus grand chose

Provider ADO : SQLNCLI11.1 ou plus récent MSOLEDBSQL.1

Là tu auras une tripotée d'options dans la ConnectionString.


BDS2006 et D10 ... je parie une fois de plus 32 vs 64bit avec un alias ODBC configuré différement.

La connexion est paramétrée dans les sources de données ODBC de la machine par l'éditeur.
Ré-utiliser la connexion existante aurait dû me permettre d'établir la connexion sans avoir à me poser de question.
Notamment pour ce qui est des droits utilisateurs puisque c'est la connexion utilisée par le logiciel métier.

Soit dit en passant, la connexion à la base de données est établie sans problème et le requêtage d'autres tables est également OK.

Je vais faire un programme de test avec différents composants pour voir si ça change quelque chose

Citation:

---

Envoyé par Mirande

La connexion est paramétrée dans les sources de données ODBC de la machine par l'éditeur.

---

Si c'est la bonne qui est utilisée, je ne pratique jamais cette méthode, je préfère maitriser le ConnectionString car le nombre de fois où j'ai pu voir ODBC mal configuré ou incomplet (uniquement en 32 ou 64 mais pas les deux)



On ne sait jamais comme c'est un problème de user
OSAuthent=No et User_Name=...

Au cas où c'est tout simplement pas le bon user qui est utilisé et que tu sois admin avec ton OS User pour ton SQL Server local.

Citation:

---

Envoyé par Mirande

Soit dit en passant, la connexion à la base de données est établie sans problème et le requêtage d'autres tables est également OK.

---

Symptome manifeste d'une table ajouté comme objet securable sans persmissions pour l'utilisateur ... faut le vérifier !!!!

La connexion est paramétrée en Authentification SQL Server
Et je repasse le user id et mot de passe

Citation:

---

BDS2006 et D10 ... je parie une fois de plus 32 vs 64bit avec un alias ODBC configuré différement.

---

C'est aussi un doute que j'ai dans le crâne depuis le début ...

Citation:

---

Envoyé par Mirande

La connexion est paramétrée en Authentification SQL Server
Et je repasse le user id et mot de passe

---

Evidemment l'éditeur vous a crée un user dédié pour votre applicatif ... ce n'est pas le user du progiciel ?
Si oui, déjà c'est pas mal, une certaine isolation
Si non, euh ... l'éditeur n'a pas peur ... ou n'a jamais entendu parler de RGPD et de responsabilité de traitement par un sous traitant.

Citation:

---

Evidemment l'éditeur vous a crée un user dédié pour votre applicatif ... ce n'est pas le user du progiciel ?
Si oui, déjà c'est pas mal, une certaine isolation
Si non, euh ... l'éditeur n'a pas peur ... ou n'a jamais entendu parler de RGPD et de responsabilité de traitement par un sous traitant.

---

Comment dire ... en fait non !

Ca peut sembler affolant mais c'est le deuxième gros éditeur chez qui je vois ça suite à un passage récent d'une base de données Access à SQL Server Express.
La base de données est complètement ouverte.
Chez un des deux, l'utilisateur sa n'a même pas de mot de passe.

En plus, je ne suis même pas sous traitant. Je suis missionné par le client final.

Bonsoir le forum

Pour vous tenir au courant ...

Le problème vient bien des composants Delphi FireDac et non de la configuration de la base de données côté SQL Server.
J'ai testé plusieurs composants à ma disposition et tous fonctionnaient sur ma machine.
Quand j'ai demandé à mon client de tester, seuls les composants ADO permettaient de se connecter à toutes les tables sans problème. J'ai modifié mon application en conséquence et ça roule !

Le problème est résolu en utilisant les composants TADOConnection et TADODataSet.

Donc, merci Shai et Sergio pour vos pistes et conseils !!!

Bonne soirée

Fred