In an Easyflex database, I have in Startup SQL:
SQL:
create or replace view LjTestW1
as
select * from DataService.Flexwerker.Loonjournaal@efx(jaar => 2026, week => 1)
With this, I’m trying to retrieve the payroll journal from Easyflex for a period via an OData feed in Excel. In the Universal SQL editor, this query works, but unfortunately, it doesn’t appear in the OData feed. Even after clearing the cache. Does anyone have any tips?
The custom views from the Startup SQL are cached in both the EDM data model and the process (if the connection has not been interrupted for a long period). Invantive Bridge Online and Invantive App Online cache particularly aggressively, whereas the Invantive Cloud site itself does so much less and offers more control over the sessions through the “Disconnect” button in the UniversalSQL editor.
Clearing the cache removes the EDM data model and should also remove the custom view definition from the session.
Similar issues include:
Sometimes, resetting the cache seems to help, and eventually, the view always becomes visible.
It actually seems to be a bug; deploying a view for Bridge Online and App Online shouldn’t be so complex and laborious.
So far, it has not been possible to get this problem to recur consistently, which has prevented a solution.
Meanwhile, the Big Data JSON driver has become available within Invantive UniversalSQL. Like Parquet, this facilitates the fast querying of datasets from terabytes of log files.
We will use this to conduct an analysis over a longer history of the involved user in an attempt to determine the cause. Should it be found, a bug fix will be made for release 26.0 and the upcoming release 27.0.
On which server(s) did you clear the cache?
The clearing should take place on the server mentioned in the URL from which the data is retrieved.
A view from the startup SQL was missing in the OData4 feed, because Invantive Bridge Online continued to use a previously saved data model. Clearing the cache in Invantive Cloud does not affect that data model.
Composed with help from AI.
The trace covers from 22nd to 24th September 2026. All times are in UTC.
| Time (UTC) | Event |
|---|---|
| 23-09 12:04 | The database is created in Invantive Cloud without startup SQL. |
| 23-09 12:05 | The first OData4 request from Power BI. Bridge Online builds the data model with 197 tables and stores it on disk. The stored model remains valid for seven days. |
| 23-09 14:26 | The startup SQL receives a view on the payroll journal. |
| 23-09 14:31 to 14:47 | Five sessions from Power BI. In each session, Bridge Online executes the startup SQL without error. However, the data model comes from the disk cache: 197 Easyflex tables, without the view. |
| 24-09 08:39 | Another session, the same scenario. |
| 24-09 08:46 | The cache is cleared in Invantive Cloud. |
| 24-09 09:00 and 09:03 | Two sessions, the same scenario. |
| 24-09 09:06 | The startup SQL receives a view on DataService.Flexwerker.Journaalposten. Bridge Online rightly reports an error: that table requires values for the parameters year and week (itgenboe074). |
| 24-09 09:09 | The startup SQL receives the view from the inquiry. Six seconds later, the cache is cleared again in Invantive Cloud. |
| 24-09 09:10 and 09:24 | Two sessions. The startup SQL creates the view without error. The data model comes again from the disk cache, with 197 tables. |
After the first change to the Startup SQL, ten sessions worked with the old data model.
At the start of each session, Invantive Bridge Online executes the Startup SQL. The view then exists in that session. Therefore, a query on the view does work in the SQL editor of Invantive Cloud.
The list of tables for the OData4 feed comes from a separate cache: the data model behind $metadata. Invantive Bridge Online encrypts and stores that data model per user and per database on disk. The unique key for that cache only includes the database and not the Startup SQL. So after a change to the Startup SQL, the old data model continued to be used until it would expire after seven days.
The design partially accounted for this. A data model with views from the startup SQL is deliberately not saved by Bridge Online because such views can change. However, a data model stored before a view existed was not checked when read. This situation occurred here: the model of 23 September 12:05 is older than the first custom view.
Invantive Cloud and Bridge Online each have their own “Reset cache” menu option. Each option only clears the caches of their own product, and the two products run on different servers. The trace shows a reset twice on Invantive Cloud. That reset cleared the caches of Invantive Cloud, but not those of Bridge Online. A reset in Bridge Online itself does not appear in the trace.
Message 2 states that clearing the cache deletes the data model. That is true for “Reset cache” in Bridge Online, but not for the same option in Invantive Cloud.
The following improvements have been made:
The improvements are available from release 26.0.332 and in the next release 27.0.
This question was automatically closed after 1 week of inactivity. The most recent given answer was marked as the solution.
Please ask a new question in a separate topic if the issue occurs again. In the new question, please include a link to this topic by pasting its URL into the text.