If DLSync is managing any account-level object that changes the Snowflake session context (like database or schema), it breaks DLSync with the errors:
[main] ERROR com.snowflake.dlsync.doa.ScriptRepo.createScriptObject - Error SQL compilation error:
Table 'DL_SYNC_SCRIPT_HISTORY' does not exist or not authorized., while creating the object...
Similar errors are reported for the other 2 built-in metadata tables DL_SYNC_SCRIPT_EVENT and DL_SYNC_CHANGE_SYNC i.e. Object does not exist or not authorized.
The role operating DLSync does have permissions to use the configured schema, along with table creation in that schema. I can see the tables created in my configured Snowflake database and schema, a single row being created in the DL_SYNC_CHANGE_SYNC table which says CHANGE_TYPE: DEPLOY, STATUS: IN_PROGRESS, LOG: DEPLOY started., which means the configured role can write to the tables.
What I believe the problem is: DLSync does not use fully qualified table names, so when it created a database or schema, Snowflakeby default changes the session context to that new database/schema, so the non fully-qualified metadata table names the code uses now do not exist anymore in the newly created database/schema, hence breaking the tool.
Solution: use fully qualified table names for the DLSync metadata tables given by the connection, since Snowflake might switch the session context when it is interacted with.
If DLSync is managing any account-level object that changes the Snowflake session context (like database or schema), it breaks DLSync with the errors:
Similar errors are reported for the other 2 built-in metadata tables
DL_SYNC_SCRIPT_EVENTandDL_SYNC_CHANGE_SYNCi.e.Object does not exist or not authorized.The role operating DLSync does have permissions to use the configured schema, along with table creation in that schema. I can see the tables created in my configured Snowflake database and schema, a single row being created in the
DL_SYNC_CHANGE_SYNCtable which saysCHANGE_TYPE:DEPLOY,STATUS:IN_PROGRESS,LOG:DEPLOY started., which means the configured role can write to the tables.What I believe the problem is: DLSync does not use fully qualified table names, so when it created a database or schema, Snowflakeby default changes the session context to that new database/schema, so the non fully-qualified metadata table names the code uses now do not exist anymore in the newly created database/schema, hence breaking the tool.
Solution: use fully qualified table names for the DLSync metadata tables given by the connection, since Snowflake might switch the session context when it is interacted with.