Dans une base de données d’Easyflex, j’ai dans Startup SQL :
SQL :
create or replace view LjTestW1
as
select * from DataService.Flexwerker.Loonjournaal@efx(jaar => 2026, week => 1)
Avec cela, j’essaie de récupérer le journal des salaires d’une période depuis Easyflex via un flux OData dans Excel. Dans l’éditeur SQL universel, cette requête fonctionne, mais malheureusement elle n’apparaît pas dans le flux OData. Même pas après avoir vidé le cache. Quelqu’un a-t-il des conseils par hasard ?
Les vues personnalisées à partir du SQL de démarrage sont mises en cache à la fois dans le modèle de données EDM et dans le processus (si la connexion n’a pas été interrompue de manière prolongée). Invantive Bridge Online et Invantive App Online, en particulier, mettent en cache de manière particulièrement agressive, tandis que le site Invantive Cloud lui-même le fait de manière beaucoup plus limitée et offre plus de contrôle sur les sessions via le bouton « Déconnecter » dans l’éditeur UniversalSQL.
Vider le cache supprime le modèle de données EDM et supprime également la définition de vue personnalisée de la session, normalement.
Des problèmes similaires incluent notamment :
Parfois, la réinitialisation du cache semble aider et finalement la vue devient toujours visible.
De fait, il semble qu’il y ait un bug ; la mise en production d’une vue pour Bridge Online et App Online ne devrait pas être si complexe et laborieuse.
Jusqu’à présent, il n’a pas été possible de reproduire ce problème de manière cohérente, ce qui a empêché une solution d’émerger.
Entre-temps, le driver Big Data JSON est devenu disponible au sein d’Invantive UniversalSQL. Celui-ci facilite, comme Parquet, l’interrogation rapide de jeux de données de téraoctets de fichiers journaux.
Nous allons mener une analyse sur une période prolongée de l’historique de l’utilisateur concerné dans le but d’en identifier la cause. Si elle est trouvée, une correction du bug sera faite pour la version 26.0 et la prochaine version 27.0.
Sur quel(s) serveur(s) avez-vous vidé le cache ?
La vidange doit avoir lieu sur le serveur mentionné dans l’URL à partir de laquelle les données sont récupérées.
Une vue de la startup SQL manquait dans le flux OData4, car Invantive Bridge Online continuait d’utiliser un modèle de données précédemment enregistré. Vider le cache dans Invantive Cloud ne modifie pas ce modèle de données.
Composé avec l’aide de l’IA.
La trace couvre du 22 au 24 septembre 2026. Toutes les heures sont en UTC.
| Heure (UTC) | Événement |
|---|---|
| 23-09 12:04 | La base de données est créée dans Invantive Cloud, sans startup SQL. |
| 23-09 12:05 | La première requête OData4 depuis Power BI. Bridge Online construit le modèle de données avec 197 tables et le stocke sur disque. Le modèle enregistré reste valide pendant sept jours. |
| 23-09 14:26 | Le startup SQL reçoit une vue sur le journal des salaires. |
| 23-09 14:31 à 14:47 | Cinq sessions depuis Power BI. Dans chaque session, Bridge Online exécute le startup SQL sans erreur. Cependant, le modèle de données provient du cache disque : 197 tables Easyflex, sans la vue. |
| 24-09 08:39 | Une autre session, même constat. |
| 24-09 08:46 | Le cache est vidé dans Invantive Cloud. |
| 24-09 09:00 et 09:03 | Deux sessions, même constat. |
| 24-09 09:06 | Le startup SQL reçoit une vue sur DataService.Flexwerker.Journaalposten. Bridge Online signale correctement une erreur : ce tableau demande des valeurs pour les paramètres jaar et week (itgenboe074). |
| 24-09 09:09 | Le startup SQL reçoit la vue de la question. Six secondes plus tard, le cache est à nouveau vidé dans Invantive Cloud. |
| 24-09 09:10 et 09:24 | Deux sessions. Le startup SQL crée la vue sans erreur. Le modèle de données provient à nouveau du cache disque, avec 197 tables. |
Après la première modification du Startup SQL, dix sessions ont donc fonctionné avec l’ancien modèle de données.
Au début de chaque session, Invantive Bridge Online exécute le Startup SQL. La vue existe ensuite dans cette session. C’est pourquoi une requête sur la vue dans l’éditeur SQL d’Invantive Cloud fonctionne.
La liste des tables du flux OData4 provient d’un cache séparé : le modèle de données derrière $metadata. Invantive Bridge Online conserve ce modèle de données par utilisateur et par base de données crypté sur disque. La clé unique de ce cache ne contient que la base de données et non le Startup SQL. Après une modification du Startup SQL, l’ancien modèle de données est donc resté utilisé, jusqu’à ce que son expiration se produise après sept jours.
Le design prenait partiellement en compte cela. Un modèle de données avec des vues du startup SQL n’est pas intentionnellement stocké par Bridge Online, car ces vues peuvent changer. Cependant, un modèle de données stocké avant qu’une vue ne soit présente n’était pas contrôlé lors de la lecture. C’est ce qui s’est produit ici : le modèle du 23 septembre 12:05 est plus ancien que la première vue personnalisée.
Invantive Cloud et Bridge Online ont chacun une option de menu “Réinitialiser le cache”. Chaque option vidange uniquement les caches de son propre produit, et les deux produits s’exécutent sur des serveurs différents. La trace montre deux réinitialisations sur Invantive Cloud. Cette réinitialisation efface les caches d’Invantive Cloud, mais pas ceux de Bridge Online. Une réinitialisation dans Bridge Online lui-même n’apparaît pas dans la trace.
Le message 2 indique que vider le cache supprime le modèle de données. C’est correct pour “Réinitialiser le cache” dans Bridge Online, pas pour la même option dans Invantive Cloud.
Les améliorations suivantes ont été mises en œuvre :
Les améliorations sont disponibles à partir de la version 26.0.332 et dans la prochaine version 27.0.