> > By using the _screens.forms(x) array, you do have full access from > any > > form to the datasession and, in fact, any other property or method, > on > > any other form. > > True again, but is seems somehow less robust as a solution. Remember > that you are trying to trap a programming error. Some forms may be > closed, but not released, in which case you would not see the > datasession, but you could still have tables open. Yes, but in 99.9% of the cases it's the best or only solution. The only time I've heard of it not working was when a Form blew up and orphaned it's DataSession. But then the only way to close that was through the magic keyword: QUIT > > And I disagree with your comment that DataSessions are related to > > databases, rather than OOP. I would suggest that they are related > to > > _neither_. You can't subclass them, you can't change their > behaviour, > > > > etc. so they are clearly not OOP based. Additionally they aren't > > database (.DBC) related because you can have tables from multiple > > .DBCs, > > free tables, etc. in them, so they aren't related to the idea of a > > .DBC. > > > > Comments? > > I think we have definition problems here. I meant (and regretted) > that > datasessions fall into the OOP organization in VFP because you can > only > create them as a property of a form object. On the other hand I > suspect that the developers of VFP have organized the datasessions as > an > extension of the select handles. I suspect that they recompute the > select area on the basis of the datasession and the select variables > and > use 'again'. This is pretty traditional FP stuff don't you think? so > I > wonder why they did not give us full access to this information and > allow us to create our own datasessions, i.o. needing a form to do > this. One of those ideosyncraties that keeps us busy I guess. You > did > ask for comments eh! :) Yup, and yours was just the type of comment that I was looking for. I would also like to see more control over the Creation/Blow-Away-tion (sp?) of the DataSessions. Perhaps an array that enumerated them like the _screen.forms() array, and a property that tied them to a form, or something like that. Or, more simply, a DataSession that is tied to a PageFrame. But that brings up an interesting idea, that introduces a lot of overhead. Have a form that is simply used to create a DataSession. The form would never be visible, and it wouldn't be part of your forms handler, but a page on a pageframe could access the tables that were in its DataSession. This way you could have the control you wanted over a DataSession, but you'd have to go through this form as a detour. It seems workable to me! /Paul