Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Dangling Datasession after Report
Message
De
05/03/2008 06:08:10
Lutz Scheffler
Lutz Scheffler Software Ingenieurbüro
Dresden, Allemagne
 
 
À
05/03/2008 05:47:38
Information générale
Forum:
Visual FoxPro
Catégorie:
Gestionnaire de rapports & Rapports
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows XP SP2
Divers
Thread ID:
01298809
Message ID:
01298822
Vues:
26
Sergio,
this is what my update was about.

But there is reason for the way it it. The methods in the listener are called over and over (imagine a 2000 page report that is 75% black). So calling this and that what could be done strait will considerable slow down.
Anyway, I say that one need to know what one is doing. (I found some code where somebody didn't know just in the morning. ::))

Personaly, I didn't see why they need those extra datasession, it would be much simpler and faster if they would stay within the one with the data. But again, there might be reason I do not see now.

But if you realy didn't like it, feel free to rewrite. ::)
If you didn't have time to it, check the chatter forum. Some people there working not to there capacity.

Agnes
>
>All I am saying is that I simply always felt better doing
>
>oBO.InsertSomethingIntoSomeTables(SomeValues)
>*or
>oRec = oCBO.GetRecLayout(pKey)
>
>rather then then
>
>
>set datasession to B
>replace ...
>scatter name oRec
>set datasession A
>do things with oRec
>
>
>I see second aproach as sort of 'intrusive'.
>
>I saw some listener code which did simillar (second) scenario with frx session. And it looks kind of wrong and unsafe to me.
>
>As it stands now listener keeps frx datasession as a number and have couple of methods to set and reset it. That is what I believe causes bugs like this. It very easy to break this fragile balance in subclass code.
>
>Imho, oBaseListener.FRXDataSession instead of being number, should have been instead designed as propper fully blown session object acting as a sort of 'server' rather then having to *tresspass* with set datasession to ... and then get eventually caught with the bug.
>
>Instead, whatever info is normally needed from frx session, could be obtainable by doing it normal OOP way, by calling methods that return info/values.
>
>From within listener we should be able to call
>this.oFRXSession.GetFrxRec(nFrxRec)
>this.oFRXSession.GetThisOrThat(...)
>etc
>
>Destroy method of listener could safely release frx session object and reference kept in that property and nobody would ever get into any trouble with it.
>
>
>That is just my opinion.
>
>Sergio
Words are given to man to enable him to conceal his true feelings.
Charles Maurice de Talleyrand-Périgord

Weeks of programming can save you hours of planning.

Off

There is no place like [::1]
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform