These should be better options than my initial suggestion, as they seem to be more well-documented and should not depend as heavily on externally managed environments.
Using a schema other than dbo is not supported for the application model and its generated logic. The platform assumes that database objects are located in the default schema.
Technically, you can reference objects in another schema from the “Functionality”screen by using fully qualified object names. However, this is generally not recommended, as it falls outside the standard approach and can make your solution more difficult to maintain.
Could you share a bit more about why you want to use a different schema? Understanding your use case will help us suggest the most appropriate solution or determine whether there's a better alternative.
The reason we're considering using a different schema is that we're trying to connect to a Microsoft Fabric database, which is SQL Server–based. We need to access some of the data stored in Fabric for our application.
The connection details we have been provided are:
Server: [sample].fabric.microsoft.com
Database: Thinkwise
Authentication: Microsoft Entra Service Principal
App (Client) ID / User ID: [id]
Tenant (Authority) ID: [id]
Service Principal: spn-thinkwise-lakehouse-readonly
Secret: [secret key]
Our current idea is to connect to the Fabric database and copy the required data into a separate schema for use by our application.
Is there a better approach for accessing data from Fabric using the connection details above? For example, would it be possible or recommended to use a web connector given the above details or another integration method instead of copying the data into a separate schema?
We'd appreciate any recommendations on the best approach for integrating with Fabric in this scenario.
Is it possible to configure a secondary database connection in Thinkwise to connect to a Microsoft Fabric SQL database and access external data, while the primary application database remains Azure SQL Database?
We recommend storing data fetched from external sources in tables defined in the model. They can be distinguished by name and perhaps a tag. Storing them in a separate schema is not supported by the Thinkwise platform, which would mean that maintenance is entirely manual.
As for the actual integration, it is not possible to define something like a secondary database for the application. The Database connector process action might provide what you need to fetch the data you need from Microsoft Fabric.
I am trying your suggestion, to use Database Connection using a Process Action to connect from our Thinkwise application to a Microsoft Fabric Warehouse.
I created a simple process flow with a Database Connection to verify connectivity. The connection requires Microsoft Entra Service Principal authentication, and I am trying to use the following
System.Data.Odbc.OdbcException (0x80131937): ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified at System.Data.Odbc.OdbcConnection.HandleError(OdbcHandle hrHandle, SQLRETURN retcode) at System.Data.Odbc.OdbcConnectionHandle..ctor(OdbcConnection connection, OdbcConnectionString constr, OdbcEnvironmentHandle environmentHandle) at System.Data.Odbc.OdbcConnectionOpen..ctor(OdbcConnection outerConnection, OdbcConnectionString connectionOptions) at System.Data.Odbc.OdbcConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningObject) at System.Data.ProviderBase.DbConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool,
Question:
Do you know whether Microsoft ODBC Driver 18 for SQL Server is installed and available in the Thinkwise cloud environment where the Database Connection Process Action is executed?
If it is available, could you confirm whether the Database Connection Process Action supports using this driver with Microsoft Entra Service Principal authentication?
These should be better options than my initial suggestion, as they seem to be more well-documented and should not depend as heavily on externally managed environments.