Jump to content
  • 0
lem alpha

Php : Affichage De Données Liées Incohérent

Question

Hello,

en publication PHP, qu'est-ce qui pourrait provoquer que certaines données liées ne sont pas retournées correctement ?

Sur les captures d'écrans ci-dessous, vous voyez :

- le modèle FMP dans la base sur lequel est basée la page PHP. Dans l'encadré bleu, ce sont des rubriques liées. Il y a 1 seul enregistrement lié, car c'est l'enreg. parent (le lien est dans le sens "n à 1")

Certaines rubriques sont repérées par des lettres (en rouge celles à problème). Surlignées en jaune, les valeurs qui ne sont pas retournées correctement dans la page PHP.

scr_web_01_fmp.gif

- le résultat affiché par la page PHP. J'ai ajouté une ligne de test, sous le bouton "retour", qui affiche les rubriques repérées par les lettres, dans l'ordre A | B | C | D | E

A et D ne sont pas retournées correctement.

Pourtant toutes les autres, si. (et notamment C : ID de l'enreg. courant et E : ID de l'enreg. lié, ce qui prouve bien qu'on affiche les bons enregistrements.)

scr_web_01_php.gif

Je joins également le code php de cette ligne test, pour vous montrer que j'appelle bien les bonnes rubriques :

<?php echo

$InscriptionGroupe_row->getField ( 'insc_GRPE__FO_Details::Z_WEB_DeplPayes' ).' | '. // A

$InscriptionGroupe_row->getField ( 'insc_GRPE__FO_Details::Z_WEB_DeplVoitOK' ).' | '.

$InscriptionGroupe_row->getField ( 'Zkp' ).' | '.

$InscriptionGroupe_row->getField ( 'insc_GRPE__FO_Details::Z_WEB_DetailsConv' ).' | '. // D

$InscriptionGroupe_row->getField ( 'insc_GRPE__FO_Details::Zkp' ); ?>

Autre précision qui a son importance :

j'ai un autre site en publi PHP, avec exactement la même page PHP (le fichier a été copié-collé), qui attaque une autre base exactement identique (structure idem mais avec d'autres données), et cette page fonctionne parfaitement ! (ie A et D sont parfaitement bien retournées)

Là, je sèche, je ne sais plus trop où chercher...

Merci d'avance !

post-384-0-91998700-1316772298.gif

post-384-0-43141100-1316772329.gif

post-384-0-91998700-1316772298.gif

post-384-0-43141100-1316772329.gif

post-384-0-91998700-1316772298.gif

post-384-0-43141100-1316772329.gif

post-384-0-91998700-1316772298.gif

post-384-0-43141100-1316772329.gif

post-384-0-91998700-1316772298.gif

post-384-0-43141100-1316772329.gif

post-384-0-91998700-1316772298.gif

post-384-0-43141100-1316772329.gif

post-384-0-91998700-1316772298.gif

post-384-0-43141100-1316772329.gif

post-384-0-91998700-1316772298.gif

post-384-0-43141100-1316772329.gif

post-384-0-91998700-1316772298.gif

post-384-0-43141100-1316772329.gif

post-384-0-91998700-1316772298.gif

post-384-0-43141100-1316772329.gif

Share this post


Link to post
Share on other sites

6 answers to this question

Recommended Posts

  • 0

ça aurait pu être une bonne idée, mais tout est bon de ce côté...

(le compte web est en [saisie de données uniquement], donc aucune restriction particulière sur telle ou telle rubrique)

Ce qui est d'autant plus bizarre, c'est que A renvoie 0 au lieu de 1.

C'est encore pire que de ne renvoyer aucune valeur ! (comme le fait D)

Share this post


Link to post
Share on other sites
  • 0

Oui mais A est un nombre et D une chaîne normalement...

  • Le modèle en copie d'écran est bien celui qui est utilisé par l'API ?
  • Y'a un tri sur le lien ?
  • La données est à quelle distance de la table de base (nb de liens) ?
  • Il fait beau ?

Share this post


Link to post
Share on other sites
  • 0

Alors,

oui c'est le bon modèle / pas de tri / 1ère occurrence liée / oui il fait très beau merci (et encore heureux, manquerait plus que ça)

J'ai trouvé la source du problème, c'est logique comme tout, mais du coup je ne comprends pas pourquoi pour l'autre base ça marche !!!

Les rubriques A et D (entre autres) de la 1e OT liée sont des calculs non mémorisés, d'après un autre contexte ailleurs dans le graphe.

La particularité de ces 2 là (contrairement à G par ex.) est que dans cet autre contexte de calcul, un des liens fait appel à une globale, normalement définie par script à l'ouverture avec la date actuelle.

En général, je fais gaffe à ne pas utiliser des liens basés sur des globales en PHP, mais là je ne m'en rappelais plus.

J'ai donc ajouté cette rubrique globale au modèle utilisé par PHP, pour voir.

Eh bien en effet, dans FMP je vois bien 23/09/2011, mais en affichant la valeur dans ma page PHP, je vois 28/05/2011 !!!

(sûrement une valeur restée dans la globale lors d'un démontage/ouverture en local/remontage de la base pour maintenance)

Donc la date actuelle n'a pas été insérée dans la globale lors de l'accès en PHP, et ça me semble somme toute logique.

Par contre, j'ai fait le même test dans l'autre base (celle où tout marchait bien), et qui je le rappelle est en tous points identique (sauf pour les données), eh bien l'affichage de la globale par PHP renvoie bien 23/09/2011 !!

(d'où l'évaluation correcte de A et D)

Je veux bien admettre que par PHP on n'ait pas les mêmes possibilités avec des globales, mais je ne m'explique pas pourquoi sur l'autre appli tout fonctionne... :blink:

Share this post


Link to post
Share on other sites
  • 0

Salut,

A retourne une valeur booleenne, D une valeur texte, qui apparemment n'est pas du tout retournée ici. Je pense que la solution doit se trouver dans la formule de ce calcul non mémorisé, et dans ce qu'il référence très exactement. Quel est ce calcul aussi simple soit-il ?

Ugo

Share this post


Link to post
Share on other sites
  • 0

Salut Ugo,

en fait je réponds déjà plus ou moins à ta question dans mon précédent post :

c'est bien dans l'évaluation des 2 calculs qu'il y a un problème, mais à cause du lien par lequel ils passent, et qui contient une globale. (voir le détail ci-dessus)

Dans le cas où ça ne marche pas, ce lien ne se fait tout simplement pas (la globale n'yant pas la bonne valeur), d'où calcul booléen à 0 et texte vide.

En modifiant légèrement ces calculs au niveau du contexte (autre OT cible, liée sans globale), tout marche.

Mais évidemment, la pertinence du résultat retourné ne me satisfait pas totalement (même si en attendant ça ira bien), car le filtre supplémentaire amené par la globale dans le lien est relativement indispensable.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...