Le forum (ô combien francophone) des utilisateurs de Powerbuilder.
Bonsoir à tous,
nous sommes en PB 11.5.1 build 4740 et étions avant en 10.5.1 6021.
Nous sommes principalement sous Windows Xp et travaillons avec les SGBD SQL 2000/2005/2008 et Oracle 9/10.
Nous n'utilisons pas les kit locaux de Sybase c'est à dire pas le kit français. Nous utilisons les fichiers fournis nativement avec l'EBF mentionné plus haut.
Nous venons de nous rendre compte que la gestion des GetItemxxx avait changé entre les 2 versions.
En effet, les expressions suivantes ne retournent pas forcément d'erreur selon les versions :
- getItemString( 0, « xxx ») (où « xxx » est un champ existant) - Renvoie une erreur en PB 10.5 - Ne renvoie pas d’erreur en PB 11.5 (on a valeur vide) - getItemString( -1, « xxx ») (où « xxx » est un champ existant) - Renvoie une erreur en PB 10.5 - Ne renvoie pas d’erreur en PB 11.5 (on a valeur vide) - getItemString( 1, « toto ») (où « toto » n’existe pas) - Renvoie une erreur en PB 10.5 - Renvoie une erreur en PB 11.5
Est-ce quelqu'un a expérimenté quelque chose de semblable et a une solution ? Avons-nous fait de mauvaises installations de PowerBuilder ?
Ca me âraît incroyable comme changement.
Par avance merci
Razorback
Dernière modification par RAZORBACK (06-12-2010 11:34:58)
Hors ligne
Bonjour,
Pour moi, il n'a pas de changement entre la 10 et la 11. La documentation est strictement identique concernant les valeurs retournées par GetItemString :
Return values
Returns the string value in the specified row and column. Returns the empty string ("") if there is no DataWindow object assigned to the DataWindow control or DataStore or any other error occurs.
Une chaîne vide retourné en cas de demande d'une valeur inexistante, c'est conforme à la documentation.
Je ne vois pas bien l'intérêt de générer volontairement une erreur en demandant une donnée que l'on sait inexistante :
IF ll_row > 0 AND ll_row <= dw_1.RowCount() THEN ls_data = dw_1.GetItemString(ll_row, "column_xx") ELSE ... Traitement erreur END IF
Hors ligne
En fait, c'est une fonction de notre framework que nous appelons, parfois, il faut bien le reconnaître, alors que la référence de ligne n'est pas bonne (ce qui correspond évidemment à une erreur de code).
Mais là où avant on avait une erreur PB, on n'en n'a plus maintenant. Ce qui est un peu gênant car alors on ne sait plus qu'il y a erreur de code.
Avant on pouvait alors corriger, maintenant ce sera plus compliqué.
Enfin, ce qui m'étonne c'est que tu ne vois pas de différence entre les 2 versions.
Razorback
Hors ligne
Pour info, seules les fonctions GetItemString et GetItemFormattedString sont concernées.
Du coup, ce que nous avons fait, c'est coder dans les fonctions de notre framework, une vérification de la ligne (>0) avec un code encapsulé dans des DEBUG symbol de façon à ne pas alourdir le code compilé mais quand même avoir l'erreur en environnement de développement.
Le problème reste ouvert mais maîtrisé.
Razorback
Hors ligne