Skip to main content

If we run SQLExecutor in FME workspaces in FME server 2022.2.2, then we can't connect to the Snowflake datasource. We have this problem in multiple workspaces that run on FME server and for multiple Snowflake databases/schemas. It raises this error:

2023-6-29 15:14:13 | Performing query against SNOWFLAKE_NONSPATIAL dataset `snowflake_datalake_acc'
2023-6-29 15:14:13 | No SNOWFLAKE_NONSPATIAL dataset name was specified (couldn't find a value for `R_1_DATASET' or `SNOWFLAKE_NONSPATIAL_DATASET')

It has strange behaviour. When we load the same workspace, same input database/schema/role, same output database/schema/role, and different data table it can connect for some data tables, but it does not connect for other data tables. Is there a way to solve this?

 

We got this problem when we switched to a new role in FME server for authorization to databases/schemas/tables in Snowflake. We already checked the database connection configuration in FME server multiple times and it is correct since it works for some ETL pipelines with specific data tables usage?

This is a bug in FME server 2022.2.2 for Snowflake database connection when using Advanced JDBC Connection. If you only fill in the Advanced properties without the Basic properties, you get the error.

 

The workaround is to first fill in the Snowflake connection by having <Advanced - Specify JDBC Connection> on No and then fill in <Account Name>, <Warehouse>, <Database>, <Schema> and <Role>. After filling that in, you can switch <Advanced - Specify JDBC Connection> to Yes, and fill in your Advanced properties.

 

It seems there is some sort of bug which requires advanced JDBC connection in FME server to still have some properties from the basic settings? Would be nice if this can be fixed in FME server.


Hi @david_gis​, Thanks for sharing this.

I wasn't able to reproduce this with FME Desktop 2022.2.2.0 (b22782) and FME Server 2022.2.1 (b22776).

But I believe you! We have another customer reporting a similar error. They suggest that this is still an issue in 2023.0. Can you comment if you've had a chance to test in 2023.0?

Please feel free to file a case so we can possibly collect more information to help understand this. If you do please refer to this community post.

Many Thanks!


Hi Steve. We did not test this with 2023.0.


Reply