j’ai un bug dans une ancienne application que je n’arrive pas du tout à comprendre. Pour des besoins d’export, j’ai besoin de récupérer les données d’un objet et je passe par un objet temporaire :
var testId=this.getRowId();
var test =this.getGrant().getTmpObject(“CrbRechDemande”);
test.resetFilters();
if(test.select(testId)){
blablaba
}
dans certains cas, le test.select(testId) retourne false alors que l’id existe bien …
je ne sais plus ou chercher …
Une search-spec est un morceau de SQL “where” forcé
Un filter est un filtre accessible à l’utilisateur.
Regardez dans le load de l’objet ou sa définition.
ajoutez qq chose comme if (this.isTmpInstance()) this.setSearchSpec("1=1");
pour ne pas mettre de search spec pour un usage de cette instance temp.
L’utilisateur qui exécute ce code a-t-il les droits de lecture sur l’objet ?
sinon il faut lui ajouter dynamiquement via grant.accessObject ou changeAccess avant le select, et lui retirer ensuite via delAccessObject ou changeAccess. ou alors habiliter l’utilisateur qui exporte à cet objet.
En rhino on peut activer les traces SQL en joutant en début de script
console.traceObject(true)
vous verrez alors passer dans les logs le select ... where row_id=? qui ne ramène rien, et le tester unitairement pour savoir quelle jointure ne passe pas.
Il y a peut être des références qui ont été supprimées, liens morts dans la base. Si une foreign-key est obligatoire Simplicité génère un “inner join”, sinon c’est un “outer join”.
Vous pouvez donc temporairement modifier le caractère obligatoire de FK pour voir si cela vient de là.
|CrbRechDemande.prepareScript||Erreur évaluation script: sun.org.mozilla.javascript.internal.EcmaError: TypeError: Cannot find function traceObject in object com.simplicite.util.ScriptInterpreterConsole@2ce2849. (#1) in at line number 1
on peut le faire via this.setParameter("LOG_SQL_USER", "yes"); dans le postLoad.
mais cela ne marchera pas forcement si vous êtes sur une version qui ne sait pas le faire.
ou sinon on peut toujours activer les traces globales via param système LOG_SQL_USER=yes (de la V2) mais c’est très lourd en log et en perfs.
si vous suspectez des pb de joinuture, il est préférable de faire des “select where not exists” via un accès SQL pour retrouver les liens morts et les corriger.
Ok donc je ne vois pas trop ce qu’on peut faire au niveau socle pour vous aider à ce niveau (surtout sur une V3.0 qui n’est plus maintenue).
La question de fond est sur le “inner join” ou “left outer join” au niveau des accès base de données.
Tout passer en jointure externe ne fera pas régresser les FK obligatoires, et permettrait de “voir” les objets ayant des liens mort (champs vides à l’écran). Ce serait moins bloquant pour l’utilisateur qui pourra alors modifier/corriger les liens morts.
C’est du même ordre que d’avoir uniquement des colonnes NULL en base alors que les champs sont obligatoires dans les objets suivant le contexte, ou afficher le “code” de liste de valeurs à la place de son libellé si le code est inconnu…
Il faut que la base reste un espace de stockage indexé et transactionnel avec le moins de règle métier possible.