Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Base Grid on Cursor -- Any problems? Any Tricks?
Message
De
15/01/2000 09:33:56
 
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Gestionnaire d'écran & Écrans
Divers
Thread ID:
00317290
Message ID:
00318538
Vues:
34
>Again, sorry for jumping into this thread, but this question is very interesting to me too. I understand, if a form has it's own private DS, there is no way to pass it's cursors back. So, what's the solution here? Preparing these cursors in the calling program? We can not pass an array back in UnLoad method, Ed Rauh already told me that. We can create a custom object with an array property, instanciate it before the form's call and then retrieve an array of our changes. Right? But for me this method seems to be combersome. My question is: what could be other solutions in this situation?
>

Basically, I don't have this situation. If I have two processes that need to share data, I ensure that they live in the same datasession. I find that logical program architecture lines it up for me this way. Say I have a form for maintaining a table. I have another form that needs to run a series of processes on that same table, and the first form views the results. The first form will have a private datasession, the second will use the default. Forms using the default datasession don't actually use the default datasession, but the datasession of the object that called them. So these two forms can easily share data, all the while keeping the data "private" from the rest of the application.

It was someone from the Fox team (Randy Brown?) that I heard at DevCon when being asked questions about SET DATASESSION said something along the lines of "SET DATASESSION is not really designed to be used in production code- we put it in there to make it easier to write diagnostic tools, and to help you debug."

I am not in a position to agree or disagree with this statement, but I DO feel that most code that uses SET DATASESSION has approached the design wrong. If you have laid out object responsibilities correctly, made wise use of Private Datasession and Default Datasession, and instanciated objects from the most logical places, you simply won't have the need for SET DATASESSION, and you won't have the need to pass entire cursors around.

Most of what people want to do with entire cursors can be done with just a primary key, or list of primary keys. In all cases I have found, any data that NEEDS to span datasessions cen be written to disk and retrieved by the other datasessions.
Erik Moore
Clientelligence
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform