Erreur 3184 pour toute modification en VBA après modification du schema DBO

Voici mon pb :
J'ai créé une base dans SQL Server 2016 Express, il y a 3 mois. Depuis, je crée une application avec ACCESS comme IHM ( en langage vba).
Les tables de la BD SQL sont attachées dans mon applli Access.
Tout fonctionnait bien avec le schema de base 'dbo'.
Ajourd'hui je l'ai modifié en 'opa' pour pouvoir gérer les permissions plus facilement (d'après ce que j'ai compris). Depuis je peux attacher les tables SQL dans Access
mais dès que je modifie une donnée Access j'ai une erreur 3184 " la table est introuvable".
Sous SSMS, si je modifie : j'obtiens le message " ... source d'erreur : .Net sqlClient DataProvider. Nom d'objet 'dbo.t_users' non valide : alors que la table est bien affichée opa.T_users ! )
Je pense que j'ai créé incomplètement le nouveau schéma. Voici ce que j'ai fait:

Code:

---

1 2 3 4

-- sous SA CREATE SCHEMA opa -- ensuite pour chaque table ALTER SCHEMA opa TRANSFER dbo.T_users

---

Ca fait quelques heures que je tourne en boucle ...
Merci à tous ceux qui pourront m'éclairer !

Il faut nommer vos tables opa.T_users dans les objets ACCESS sinon il essaye toujours de les chercher dans le schéma SQL dbo...

A +

Merci de votre réponse.
Pourtant, j'essaie de reproduire le mécanisme d'une appli que j'ai créée en 2009 pour une assurance avec Access et Sql Serveur 2005 (qui a migrée depuis en 2008 puis 2012) et qui fonctionnait très bien.
A l'époque, ce n'est pas moi qui avais mis en place les utilisateurs et les privilèges sur la base.

Dans mon appli actuelle, sous Access, le nom de la table liée ne comporte pas le schéma. Mais je vérifie :
currentdb.tabledefs("T_contrat").connect = ODBC;DSN=CNX_OPERA_DEV;Description=développement OPERA;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=OPERA_DEV;ServerSPN=XPS15-51BMC3A\SQLEXPRESS;
currentdb.tabledefs("T_contrat").SourceTableName = opa.T_contrat
Un autre point : Access n'accepte pas de . dans le nom d'une table liée ou locale.

En fait, C'est la création de mon SCHEMA opa dans ma base qui n'est pas correct. j'ai déjà l'erreur en modification sous SSMS. Effectivement il essaie de retourner la modfi à dbo.T_contrat !
Donc il faut que je complete mon schema opa en l'attribuant à un role mais lequel ?
Mon but est raisonnable : j'ai une trentaine de tables et je veux attribuer les mêmes permissions à tous mes utilisateurs (authentification Windows) qui sont dans un groupe windows usersOpera

A+

Vous mélangez beaucoup de chose. Un schéma SQL est un conteneur d'objet au même titre qu'un tiroir d'une commode. Il n'a rien à voir au niveau de la sécurité. Mais il est vrai que Microsoft SQL Server entretient la confusion en ayant un schéma SQL de nom dbo et un utilisateur SQL de nom dbo. Ces deux objets n'ayant rien à voir l'un avec l'autre. C'est un peu comme si vous me parliez de R6... qui peut être indifféremment :
une voiture de Renault : https://www.google.com/url?sa=i&url=...AAAAAdAAAAABAO
une moto de Yamaha ! : https://www.google.com/url?sa=i&url=...AAAAAdAAAAABAE

A +

Je suis évidemment pour le moment un peu perdu face à la diversité des concepts nécessaires à l'administration de SQL S !
Cependant mon pb est simple :
Dans SSMS tout fonctionnait bien dans ma base avec le schema par défaut dbo
je modifie ce schema en opa connecté avec sa , je ne peux plus modifier aucune donnée

En fait je cherche des bons exemples de création de schema et aussi d'affectation de permission. On trouve surtout via Google des exemples partiels dénués de contexte.
A+

Il n'y a pas d'intérêt pour une petite base d'avoir déplacé vos objets de dbo à un nouveau schéma. L'intérêt de la notion de schéma SQL est évident dans deux cas de figure :
la base comporte beaucoup d'objets : exemple SAP (30 000 tables)... Comment retrouver les tables de la comptabilité, la production, la RH ? En les ayant ventilées dans différents schéma.
la base nécessite des accès très différents en fonction de la conjonction utilisateur/objets. Par exemple, l'utilisateur "Producteur" a les privilèges de lire/écrire les données dans le schéma "Production", de lire mais pas écrire dans le schéma "Référentiel" et aucun privilège dans aucun autre schéma.

En dehors de cela déplacer des objets d'un schéma a un autre en croyant avoir réglé les privilège n'a aucun sens.

À me lire : https://blog.developpez.com/sqlpro/p..._et_utilisateu

A +

Merci, SqlPro. Je vais approfondir tout ça et notamment l'article de ton blog.

Finalement je suis revenu au SCHEMA dbo et tout est rentré dans l'ordre (reste un soupçon de frustration)
Merci SqlPro

Citation:

---

Envoyé par SQLpro

Il n'y a pas d'intérêt pour une petite base d'avoir déplacé vos objets de dbo à un nouveau schéma. L'intérêt de la notion de schéma SQL est évident dans deux cas de figure :

• la base comporte beaucoup d'objets : exemple SAP (30 000 tables)... Comment retrouver les tables de la comptabilité, la production, la RH ? En les ayant ventilées dans différents schémas.
• la base nécessite des accès très différents en fonction de la conjonction utilisateur/objets. Par exemple, l'utilisateur "Producteur" a les privilèges de lire/écrire les données dans le schéma "Production", de lire mais pas écrire dans le schéma "Référentiel" et aucun privilège dans aucun autre schéma.

En dehors de cela déplacer des objets d'un schéma a un autre en croyant avoir réglé les privilèges n'a aucun sens.

À me lire : https://blog.developpez.com/sqlpro/p..._et_utilisateu

A +

---