Hi chunheng 
Look in the runtime/tmp for the sql creation script. You DEV folder wasn't created properly so some DEV db user accesses are not set correctly.

Hi Mr. Bruno Gonzalez ,

DEV folder is running over a year so it is not an import issue in this case. It is created fresh from Sage X3.

However, I do noticed a vandalism of the DEV user's database role membership where it has access to all `db_*` groups rather than just `db_ddladmin` and additional access to every endpoint's `_ADX` database role.

I have also observed that Accounting Task are all unusable, including SEED folder.

Interesting chunheng, someone must have broken the access rights. Can you access runtime/tmp and look for the database creation script ?
DEV db user details should be found here

From Syracuse's Batch Server:

Crosschecking with runtime/tmp equivalent at `adonix_12196_0.tra` (3k lines with fields and numbers so I am posting details of interest as it contains some relatively sensitive data like server hostname):

The critical error point is cut off so I won't know other than it's definitely a permission issue, but who?

I will need to find my DBA book to catch all the error logging by Sage X3 attempting to create the accounting task entry inside the SQL Server, from SQL Server side.

Side note: Sage Community Hub is preventing me from posting SQL Queries found in runtime/tmp copied from Notepad++.

Have you checked the SQL Server error log ?

Using this Microsoft link for help: https://learn.microsoft.com/en-us/sql/relational-databases/performance/view-the-sql-server-error-log-sql-server-management-studio?view=sql-server-ver16

No information from the default SQL Server logging settings.

Checking in with this vaguely related Sage community hub thread:  Error 76 : SQL Server Error [Microsoft][ODBC SQL Server Driver][SQL Server]The SELECT permission was denied on the object 'AFONCTION' 

User rights issue in SQL Server has been confirmed.

DEV folder is not in `X3_ADX_SYS` Securable list.

Same for DEV schema in `DEV_ADX`

From `create-application-sql_DEV.sql`, running the following added DEV schema to the DEV series role's securable.

```

GRANT ALTER, CONTROL ON SCHEMA::DEV TO DEV_ADX
GRANT SELECT ON SCHEMA::DEV TO DEV_ADX_R
GO

GRANT ALTER, CONTROL ON SCHEMA::DEV TO DEV_ADX_H
GRANT SELECT ON SCHEMA::DEV TO DEV_ADX_RH
GO

```

Somehow, the Accounting Task is fixed.

Crosschecking with other Sage X3 implementation, the DEV series role should also access to the DEV schema tables with CREATE, READ, UPDATE, and DELETE which I am checking now at the moment.

Example from `SEED_ADX`:

I will send DEV folder over to X3's folder validation to see if Sage X3 can help in adding in the securable as part of its own black box validation works.

Good, happy that the installation script fixed it.

Checking in from my company's internal archive kb, it actually happened before in 2020.

The last time I did the post-mortem is because a newly created user, from SSMS GUI, accidentally took over the Owned Schema away from `dbo` user, causing permission loss for the endpoint folder (in this case, DEV folder).

The proper method is to take the folder's database role membership but this is a common newcomer error since I did this error before, once accidentally on client's production and another as a deliberate effort in lab to confirm my mistake.

Short term resolution is to provide the folder's schema back to the folder's database role like so:

```sql

GRANT ALTER, CONTROL ON SCHEMA::DEV TO DEV_ADX
GRANT SELECT ON SCHEMA::DEV TO DEV_ADX_R
GO

GRANT ALTER, CONTROL ON SCHEMA::DEV TO DEV_ADX_H
GRANT SELECT ON SCHEMA::DEV TO DEV_ADX_RH
GO

```

To add back the rightful access to all the table, on the folder once you have access, run a Complete Dictionary Validation (VALDICO; Complete) or folder validation (VALDOS) from X3 folder and check back tomorrow.
The table permissions will be added by Sage X3 as part of its internal validation run.
Check for errors and warnings.