It is complaining as the atlas user the user that you specify in setting.xml for example ohdsi_app_user or what every is it in your case doesn’t have access to the result schema cohort_inclusion table.
You can just do grant access to that table in your postgresql for the ohdsi app user or the user that you are using to connect atlas to webapi.
If you could get the execution ID you can also find out the exact error query in the database. But for me it looks like either the table cohort_inclusion is not present or doesn’t have permission for atlas application to make changes.
Just want to clarify something: the ohdsi_app_user is the account used for access to the WebAPI schemas. There are a completely different set of credentials (and jdbc URLs) that is put into the ohdsi.source table in the WebAPI database which is used to connect and execute queries on your CDM database.
The error reported is talking about a statement being executed on the CDM database. Check the credentials you are using to connect to the CDM database via the source table.
I checked for the user that was part of JDBC connection strings in webapi.source table and ensured that it has access to results schema. This resolved the error encountered in DELETE operation.
The first thing I verified was that the user part of JDBC in webapi.source table has SELECT permission to the CDM tables in omop database.
I also verified that the logged-in user too has SELECT permission to the CDM tables in omop database.
The connect privilege is a specific type of grant you need to grant to the user connecting to the database, that is a higher level permission than a grant to select tables. It’s strange that you resolved the ‘delete’ operation (assuming this requires a connection to the database) but now you are encountering a connect error.
Only thing I can recommend is check permissions again, and check your PG documentation about the CONNECT privilege.
yes, this is a legacy set of cohort reports that you can generate by doing either the ‘full analysis’ or ‘quick’ analysis. These reports will eventually be replaced by Cohort Characterization, but if you are curious you can do a quick analysis to see some high level reports (that should take 10-20 minutes depending on your hardware). The Full Analysis could take much longer (1+ hours).
At this point, I’d recommend you play with Cohort Characterization by creating a new Cohort Characterization design, add a few features like condition occurrence long term drug era long term, and procedure occurrence long term. These will give you some baseline counts of conditions, ingredients and procedures that occurred in the cohort within the 365 days prior to index.