We are using Datalake as a centralized repository for raw data coming from D365, the goal is to integrate Datalake with Onestream directly but we are running into a "NO_BROWSETTABLE set to OFF" error. Our DEV team can stand up an azure sql server and write the data to that server....Doable but not ideal. How are you all setting up Integrations with non-odbc connections?
I don't know the first thing about Datalake, but the message you mention points to the following
SET NO_BROWSETABLE ON is an undocumented option performed for Remote Data Service (RDS) ActiveX Data Connector (ADC) connections to SQL Server. Enabling this option makes every SELECT statement act as though FOR BROWSE had been appended to the statement, but bypasses the temporary table that FOR BROWSE normally pipes the results through. The net effect is to add keys and timestamps to the query as hidden output columns so the client can update specific rows (updateable cursors) without separate trips to the server to pick up the meta-data and munging the query to get the appropriate columns.
As for "How are you all setting up Integrations with non-odbc connections?", I would say that it's up to your configuration of the .Net environment you're running OS in (installing drivers etc). For example, anything that opens connections through ADO.Net will probably work just fine from OS rules.
I have just begun encountering this for one of my clients. Their current data lake is azure synapse. For some hyper-secure data, they recently stood up a new serverless instance. Connecting to that instance via data adapters has worked fine, but when I tried to make my normal connector, it hit this same error.
Running sql profiler on a local lab, I can see that the typical call (using BRApi.Database.ExecuteSql) wraps the sql in NO_BROWSETABLE OFF/ON set statements. Apparently this is not supported for the serverless, so it was failing.
My workaround has been to set up a parameterized data adapter to support the desired integration query. Then I'm fetching it as a dataset instead of a dataadapter (BRApi.Dashboards.Process.GetAdoDataSetForAdapter).
One other wrinkle we just encountered, the pure existence of this external connection seems to have broken our table data manager dashboard. I was able to fix part of this, but it still fails on some of the pages. Very frustrating since I have no apparent control over this property SET...
have you tried ExecuteSqlUsingReader instead?
I think BRApi.Dashboards.Process.GetAdoDataSetForAdapter uses DbSql.GetDataTableUsingReader behind the scenes which is what ExecuteSqlUsingReader also does.