Le forum (ô combien francophone) des utilisateurs de Powerbuilder.
Bonjour,
Pour information, nous venons de découvrir un beug sur la syntaxe du GetItemString à partir de la version 11, que nous avons remonté à sybase, mais qui n'est pas encore corrigé.
Le beug est le suivant : Le GetitemString avec un row à zéro provoquait une erreur Invalid Row/column avant , ne fait plus d’erreur depuis la 11.1 , alors que le row zéro n'existe pas dans la datawindow
Réponse de sybase
=> J'ai bien reproduit ce problème sous PB 12.1 et 12.5, et qui est en fait une regression, probablement à cause de la correction du CR# 547953 "GetItemString function will execute the computing row not existing.". Il a été remonté à l'Engineering sous le numéro de CR 657168 "RuntimeError no longer raised when accessing a non existing row" et n'a pas été encore corrigé à ce jour.
Donc méfiance dans votre code,
Hors ligne
En attendant, tu peux toujours surcharger les méthodes GetItemString dans un ancêtre commun à tes DW
Merci de l'info en tout cas.
Hors ligne
Oui, bien sur, nous avons contourné le problème, c'était pour faire profiter la communauté de notre expérience,
Hors ligne
une regression, probablement à cause de la correction
Sybase...
Sera corrigé dans un prochain EBF qui cassera quoi d'autre ? Mince, il ne connaissent pas les test unitaires ??
Hors ligne
Et pour demander la correction , suite de la réponse de sybase
Sybase a écrit:
Si vous souhaitez une correction rapide de ce CR, vous pouvez faire la demande de hotlist en fournissant un Business Case pour justifier la demande d'augmentation de la priorité du CR. Je vous envoie les détails dans l'email suivant.
et
Sybase a écrit:
Voici donc les questions clé à répondre pour préparer votre Business Case si voussouhaitez mettre le CR 657168 sur la hotlist:
-------------------------------------------------------------------------------------------------------------------------------------------------
In order to request a bug fix we need to provide a business case. The business case allows us to prioritise for engineering the importance of getting a particular bug fixed. When a business case is submitted it must contain the following detailed information:
The impact that the product defect has on the customer, whether it be tangible (e.g. revenue/business lost) or intangible (e.g. migration deadline postponed/missed), and the impact on Sybase, Inc. (financial, publicity, etc.).
Where appropriate please provide examples, metrics and monetary costs.
1. What is the exact impact of the product defect on your environment ?
2. What environment is this product defect affecting ( production, user acceptance testing, development etc ) ?
3. If the defect is affecting production, what is its impact on your business ? How many clients/users is this
affecting ? Is there any impact to your revenue ?
4. If the defect is affecting testing or development is the defect preventing migration to production ?
How many users/developers is this affecting ? What are the implications for your project timescales? What are these timescales?
5. Is there any other scenario in which this defect is impacting you or your business operation ? Is there a risk to
personal injury or loss of life
6. Can you workaround the problem ? If you can workaround the problem how easy/difficult is it? How long and what will it
cost you to implement a workaround to the problem ?
7. Is there any other relevant information that may have been omitted from above ?
-------------------------------------------------------------------------------------------------------------------------------------------------
Autrement dit, à ce jour personne n'a demandé la correction, et je n'étais pas la 1ere à remonter le problème,
Hors ligne
wazou1812 a écrit:
Autrement dit, à ce jour personne n'a demandé la correction, et je n'étais pas la 1ere à remonter le problème,
Ah oui, le coup du "business case"... On a déjà donné : dans le cadre contractuel de notre support, on a déjà remonté plusieurs problèmes (pour la plupart, des bugs du moteur des datawindows). Résultat : pour le meilleur cas, Sybase a tenté de nous fournir un contournement du bug (qui ne pouvait pas s'appliquer dans notre cas), et sinon nous a demandé de justifier commercialement l'importance du problème (le "business case" nombre de clients installés, impact commercial) et vu qu'on en a qu'une petite[1] on pouvait aller se rhabiller avec notre bug car il n'était pas sur la liste de ce qu'il était prévu de corriger. Faut dire qu'on tourne en PB classic et que Sybase roule maintenant pour .NET (et que vu la catastrophe au niveau des corrections de classic, il ne doit plus rester que des stagiaires pour faire la maintenance), mais quand même.
Conclusion si t'es trop petit, t'es juste bon à payer pour un support virtuel, mais il ne faut surtout pas imaginer qu'il corrigeront les problèmes si ce ne sont pas les mêmes que ceux des "gros"...
Tout ce qu'ils ont gagné, c'est qu'on a résilié le support.
Et qu'on se tâte pour passer à 12.5 classic... ou pas.
[1] - comprendre : petite base client
Dernière modification par seki (14-03-2012 09:39:40)
Hors ligne
Et c'est à partir de combien que Sybase considère qu'elle est grosse [1] ?
[1] - comprendre : grosse base client
Hors ligne