Bonjour Cannavaro,

Tu peux utiliser la propriété Retrieve.AsNeeded en la positionnant à Yes.

[Edit] Grillé par erasorz

cannavaro a écrit:

Salut à vous deux et merci pour votre aide,

en fait, j'ai essayé retrieve.asneeded, en utilisant cette option, PB ne se plante pas mais me retourne uniquement 16 rows ( sur 250.000 rows ! ) alors que j'ai besoin de toutes les lignes , est-ce que je doit boucler ??

Je crois que je n'ai pas bien compris comment utiliser cette option.

Je crois que c'est en fonction de la où tu te trouve sur la DW. Tu as mis une Scrollbar verticale ?

La propriété Retrieve.AsNeeded retourne seulement le nombre de lignes suffisant pour s'afficher totalement dans la datawindow. Pour récupérer les lignes suivantes, il suffit de faire défiler la scrollbar verticale de la datawindow (A noter que le type de datawindow n'a strictement rien à voir avec la présence ou non d'une scrollbar: si tu ne définis pas dans les propriétés du controle qu'il faut afficher une scrollbar, tu n'en auras pas)
Pour plus d'infos:

Tu as essayé en codant un Scrolltorow à la dernière ligne affichée + 1  jusqu'à ce qu'il n'y ait plus de lignes à charger?

cannavaro a écrit:

P.S. : La solution de diminuer le retour de la requête en rajoutant des clauses WHERE n'est pas envisageable car même si ça peut marcher, ce n'est pas une solution définitive car la base est régulièrement alimentée.

Sans connaitre exactement ce que tu veux faire c'est difficile de te répondre mais est tu sur et certain d'avoir besoin de récupérer autant de lignes ?

si oui tu peux aussi voir si tu retrieve uniquement les colonnes dont tu as besoin (pas besoin de ramener toutes les colonnes d'une table si il n'y a que l'id de la ligne et par exemple une colonne "montant" qui seront utilisés par après.

Je ne comprends pas le "car même si ça peut marcher, ce n'est pas une solution définitive car la base est régulièrement alimentée."

Admettons par ex que tu fasse une procédure pour calculer des salaires j'imagine que dans ton query tu vas ajouter une clause where sur l'année voulue pour le calcul et donc éviter de récupérer à chaque fois toutes les lignes de ta DB.

Car même si tu arrives à t'en sortir avec Retriev As Needed je pense que c'est partir sur une solution "bricolage" que tu risques de regretter par après et de plus tu vas mettre le PC qui va faire tourner ça sur les genoux vu que il va devoir swapper comme un dingo pour gérer autant d'infos.

My 2 cents, sais pas si ça peut aider

Dernière modification par rincevent (09-06-2008 15:33:25)

Je pense effectivement qu'il y a un problème de conception à la base du problème.

Malgré tout, si tu veux vraiment charger tes 220000 lignes dans PB (aïe la mémoire du poste), tu peux quand même ajouter 2 arguments à ton retrieve : li_min, li_max et ajouter dans le where de ta requette oracle where rownum >= li_min and rownum <= li_max.
Ainsi tu pourras ramener des blocs de lignes de ton resultset et les traiter un par un. Ex : retrieve(arg1, arg2, 0, 10000) puis retrieve(arg1, arg2, 10001, 11000), etc...

Chrnico a écrit:

Je pense effectivement qu'il y a un problème de conception à la base du problème.

Malgré tout, si tu veux vraiment charger tes 220000 lignes dans PB (aïe la mémoire du poste), tu peux quand même ajouter 2 arguments à ton retrieve : li_min, li_max et ajouter dans le where de ta requette oracle where rownum >= li_min and rownum <= li_max.
Ainsi tu pourras ramener des blocs de lignes de ton resultset et les traiter un par un. Ex : retrieve(arg1, arg2, 0, 10000) puis retrieve(arg1, arg2, 10001, 11000), etc...

long ll_count
long ll_pas = 10000
long ll_i = 1

do while ll_count > 0
   ll_count = ma_dw.retrieve(arg1, arg2, ..., 1 + (ll_pas * (ll_i - 1)), ll_i * ll_pas)
   ll_i ++ 
  // Je traite mon bloc de lignes
loop

De plus, je pense necessaire d'attirer votre attention sur un des danger du retrieveAsNeeded : si ta datawindow partage sa transaction avec au moins une autre, il faut eviter le retrieveAsNeeded, car alors un curseur restera ouvert sur ton serveur, dans le but de recuperer progressivement le reste des lignes, ce qui poserait de gros probleme si la meme transaction recevait entre temps d'autre SQL statements (insert, update,...). Je ne sais pas en Oracle, mais en SQL Server et ASA c'est un probleme de conception recurrent... Apres tout, c'est du dirty fixing

De toute facon, je crois que la question ne se pose pas, dans ton cas, tu dois absolument suivre le conseil de Foon: procedure, procedure, procedure! Si ton resultSet fait vraiment 100Mb, tu n'aura aucune maniere de ne pas saturer le poste client qui aura le malheur de lancer ton retrieve...

Good luck

Je suis assez d'accord avec vous. Si le but est de traiter le resultset pour en extraire une information condensée ou faire de la mise à jour en base, autant le faire en procédure stockée , mais malheureusement ce n'est pas toujours le cas. Surtout en banque...
Par exemple, si notre amis cherche à alimenter une position dans une autre application via un feed (Tibco RdV, MQSeries ou Swift par exemple), il devra bien extraire ses données de la base à un moment ou un autre... Et là pas moyen de faire l'impasse. Reste à morceller le resultset pour le traiter par bloc. Pour cela, le RetrieveAsNeeded n'est pas la solution (datastore), mais l'utilisation du rownum Oracle me semblait un bon moyen...