docs(features): cover Users & Roles on SQL Server and Oracle

databases/mssql.mdx

@@ -127,6 +127,10 @@ Every result set a batch returns opens in its own result tab. In a batch of plai
 
 **File > Import** runs a `.sql` file that holds a `GO` line the same way, `GO 5` included, and never sends a `GO` line. A file with no `GO` line runs one statement at a time, split at each `;`: dumps from TablePro 0.75 and earlier have none and import this way. End such a file with a `GO` line to run it as one batch instead. A failure is reported at the line its batch or statement starts on, and its error names the line in the file: `Failed at line 3. Line 5: Invalid object name 'orders'.` A batch past 64 million characters, about half of what SQL Server takes in one request, ends at its next `;`.
 
+## Users & Roles
+
+**Database > Users & Roles** manages logins, users, server and database roles, and permissions. Changes are staged and shown as SQL before they run. See [Users & Roles](/features/users-roles).
+
 ## SSL/TLS
 
 New connections start on **Preferred**, which encrypts the login and leaves queries and results in plain TCP unless the server forces encryption. Pick **Required (skip verify)** or stricter to encrypt the whole session.

databases/oracle.mdx

@@ -149,6 +149,10 @@ Grid edits, deletes and filters spell dates and timestamps in a form that does n
 
 Anything else renders as `<unsupported: type>`. Report those through [GitHub Issues](https://github.com/TableProApp/TablePro/issues).
 
+## Users & Roles
+
+**Database > Users & Roles** manages users, roles, and system and object privileges. Changes are staged and shown as SQL before they run. See [Users & Roles](/features/users-roles).
+
 ## SSL/TLS
 
 New connections default to **Disabled**, and there is no opportunistic upgrade: **Preferred** connects in plain TCP, which is why the Network tab flags it in red. **Required** is TCPS. **Verify CA** checks the server's certificate against the file in **CA Certificate** and skips the hostname, so it needs a CA certificate: without one, the connection is refused. **Verify Identity** checks the hostname as well. See [SSL/TLS](/connections/ssl).
@@ -164,7 +168,6 @@ The SSL mode offers no certificate rows there, so **Verify Identity** checks the
 - No OS auth, wallets, Kerberos, or LDAP. Create a database user with a password and connect as that.
 - BFILE columns show the directory and file name, never the file's contents.
 - SQL*Plus commands such as `SET SERVEROUTPUT ON`, `SHOW ERRORS` and `EXEC` are not SQL and fail when sent. Delete them, and write `EXEC p` as `BEGIN p; END;`. Output needs no `SET SERVEROUTPUT ON`.
-- No Users & Roles pane. Manage accounts with `CREATE USER` and `GRANT` in the editor.
 - A view definition longer than 4000 bytes cannot be read. **Show DDL**, **Copy DDL**, **Edit View Definition** and SQL export report it instead of showing cut text. Read the full definition in SQL*Plus or SQLcl.
 - On a database whose character set is not Unicode, filters, imports, Copy To and copied SQL still send NCHAR, NVARCHAR2 and NCLOB text through that character set, so a character it lacks becomes `¿`. Write such values with `UNISTR` in the editor.
 

features/users-roles.mdx

@@ -5,7 +5,7 @@ description: "Manage database users, roles, and privileges without writing GRANT
 
 Nothing here touches the server on its own. A privilege you select, a password you set, an account you drop: all of it stages until you open the review sheet, read the exact `GRANT` and `REVOKE` statements, and press **Execute**.
 
-Available on MySQL, MariaDB, PostgreSQL, and PGlite. Open it from **Database > Users & Roles**; the command is dimmed on every other connection.
+Available on MySQL, MariaDB, PostgreSQL, PGlite, SQL Server, and Oracle. Open it from **Database > Users & Roles**; the command is dimmed on every other connection.
 
 <Frame caption="Users & Roles: accounts on the left, objects in the middle, privileges on the right">
   <img className="block dark:hidden" src="/images/users-roles.png" alt="Users and Roles tab with the account list, object tree, and privilege checklist" />
@@ -16,10 +16,10 @@ Available on MySQL, MariaDB, PostgreSQL, and PGlite. Open it from **Database > U
 
 <Steps>
 <Step title="Create the account">
-Click **+** under the account list. The sheet asks for a kind (User or Role), a name, a host on MySQL and MariaDB, and a password; **Generate** produces a random 20-character one with the lookalike characters left out and reveals it for copying.
+Click **+** under the account list. The sheet asks for a kind (User or Role), a name, a host on MySQL and MariaDB, and a password; **Generate** produces a random 20-character one with the lookalike characters left out and reveals it for copying. On SQL Server a user is a login plus a user of the same name in the current database, and a role is a database role.
 </Step>
 <Step title="Grant the way in">
-Select the account, then the database in the Objects pane, and select **Connect** under Administration. On PostgreSQL, select the schema as well and its **Usage** privilege.
+Select the account, then the database in the Objects pane, and select **Connect** under Administration. On PostgreSQL, select the schema as well and its **Usage** privilege. A new SQL Server user holds **CONNECT** already. On Oracle, select **Server** and **CREATE SESSION** instead.
 </Step>
 <Step title="Grant the reads">
 Expand the schema, select its tables (Shift-click for a range, Cmd-click to add one), and select the **Select** privilege under Data. A privilege set against several objects of one kind is granted on all of them.
@@ -38,7 +38,7 @@ Accounts sit on the left, with a filter field and the **+** / **-** buttons. Obj
 A selected checkbox says what is granted **directly** on that object. The **Effective** column says where access actually comes from:
 
 - **Inherited from `role`**: the account holds it through a role it belongs to. PostgreSQL roles are followed transitively, and an account marked `NOINHERIT` only gets the privilege after `SET ROLE`, which the column says.
-- **Granted on `object`**: a privilege on a parent object already covers this one. Whether it does is the engine's rule: a MySQL database-level grant covers the tables inside it, a PostgreSQL one does not.
+- **Granted on `object`**: a privilege on a parent object already covers this one. Whether it does is the engine's rule: a MySQL or SQL Server database-level grant covers the tables inside it, a PostgreSQL one does not, and on Oracle only a table's privileges cover its columns.
 
 ## Granting and revoking
 
@@ -48,6 +48,8 @@ Toggling a checkbox stages a change, marked on the account, the object, and the
 
 The **Privileges / Attributes** switch opens a form for the account itself: whether it can log in, role attributes such as `SUPERUSER` or `CREATEDB` on PostgreSQL, role membership (**Member of**, with **Edit…** for a checklist), and the connection limit. These stage and apply with everything else.
 
+On SQL Server, **Can log in** enables or disables the login; on Oracle it unlocks or locks the account. A role there never logs in, so the switch is off for roles.
+
 **Change Password**, in the context menu and on the Attributes form, sets a new one. Statements that carry a password are never written to [query history](/features/query-history), which is stored unencrypted on disk. The review sheet still shows every one of them.
 
 `ALTER USER` does not exist on MySQL before 5.7.6 or MariaDB before 10.2. A password and a connection limit go in there as `GRANT USAGE ON *.* … IDENTIFIED BY` and `GRANT USAGE ON *.* … WITH MAX_USER_CONNECTIONS`, which needs `GRANT OPTION` as well as write access to `mysql.*`.
@@ -56,9 +58,9 @@ The **Privileges / Attributes** switch opens a form for the account itself: whet
 
 The bar at the bottom counts staged changes. **Discard** throws the set away; **Review & Apply…** shows every statement, including the ones that remove access, with **Copy All**, **Open in Query Editor**, and **Execute**.
 
-PostgreSQL runs them in one transaction, so a failure rolls the set back. MySQL commits user management statements implicitly, so a failure there leaves the earlier ones applied and reports how many. A successful apply re-reads the server. Changes take the same guards as any other write: a read-only connection blocks them, and [Safe Mode](/features/safe-mode) asks for confirmation or authentication as configured.
+PostgreSQL and SQL Server run them in one transaction, so a failure rolls the set back. MySQL and Oracle commit user management statements implicitly, so a failure there leaves the earlier ones applied and reports how many. A successful apply re-reads the server. Changes take the same guards as any other write: a read-only connection blocks them, and [Safe Mode](/features/safe-mode) asks for confirmation or authentication as configured.
 
-An apply made while a transaction is already open on the connection joins it instead of opening one of its own. The statements are pending in that transaction until you commit or roll it back, and the failure sheet counts them as pending rather than as written.
+On PostgreSQL and SQL Server, an apply made while a transaction is already open on the connection joins it instead of opening one of its own. The statements are pending in that transaction until you commit or roll it back, and the failure sheet counts them as pending rather than as written. MySQL and Oracle would commit that transaction before the first statement, so the apply is refused until you commit or roll it back.
 
 <Danger>
 Dropping the account this connection uses, altering it, or revoking every privilege from it is called out in the review sheet before the SQL runs. It is not blocked: revoking your own admin rights can be deliberate.
@@ -74,10 +76,23 @@ On PostgreSQL a role that owns objects cannot be dropped outright, so a sheet as
 `REASSIGN OWNED` and `DROP OWNED` reach only the database you are connected to, plus shared objects. A role that owns objects in several databases needs the same step run in each. That is PostgreSQL behavior, not a TablePro limitation.
 </Note>
 
+## SQL Server and Oracle
+
+SQL Server lists logins, server roles, and the current database's roles and users. A login shows its server permissions under **Server** and the permissions of its user in the current database below that: `sa` holds them as `dbo`. Schemas, tables, and columns open only for the database the connection is on.
+
+- A server permission is granted in `master`, the only database SQL Server takes one in. The statement runs through `sp_executesql`, so the connection stays on its database.
+- Giving a database permission or a database role to a login with no user in the current database creates that user first.
+- Dropping a login drops its user in the current database. Its users in other databases stay, without a login.
+- Dropping a role removes its members first, since SQL Server drops only an empty role.
+
+Oracle lists every account except the ones Oracle maintains, and every role. System privileges sit under **Server**; object privileges sit on the tables and views of each schema. An account without `SELECT_CATALOG_ROLE` reads the `ALL_`, `USER_`, and `ROLE_` views instead of the `DBA_` ones: it sees every account, but only the roles and privileges it holds itself.
+
 ## Limitations
 
 - `WITH GRANT OPTION` is displayed, and never silently removed, but it cannot be edited.
 - `ALTER DEFAULT PRIVILEGES` and `GRANT … ON ALL TABLES IN SCHEMA` are out of scope.
 - MySQL 8 roles: MySQL accounts are managed as users.
 - Renaming an account.
+- SQL Server: `DENY` is not shown, a column revoked from a table-wide grant still reads as granted through the table, the permissions a fixed role such as `db_datareader` implies are not listed on it, and `EXECUTE` on a procedure is out of scope. Windows logins, contained users, and the default database and schema are managed in the editor.
+- Oracle: a column privilege cannot be revoked on its own, since Oracle revokes it from the whole table. An object privilege is revoked only by the account that granted it (ORA-01927). A user who owns objects is dropped only with `DROP USER … CASCADE` in the editor. The default tablespace and quota are set there too; **UNLIMITED TABLESPACE** under **Server** lifts the quota.
 - PostgreSQL keeps schema, table, and column privileges per database and cannot read them for a database it is not connected to. Those databases still appear, still show their cluster-wide grants, and are marked as not browsable rather than shown as empty. MySQL has no such restriction.