Table of a VFeld from a VCursor

[Ed Kleban]

On 11/21/05 2:25 PM, "Ruslan Zasukhin" <sunshine at public.kherson.ua> wrote:
  
>> 3) Leave functionality the way it is but update the document to explain the
>> way things really work; namely that in the case of a VField obtained by
>> means of one of a VCursor's field methods, that the Table property returns
>> the associated VCursor, not a VTable.  -- May not be the best naming
>> convention, may not be the best implementation, but it's darn valuable to be
>> able to access this.
>> 
>> I should probably write up a request for this as well under the "Fix
>> Documentation" category.
> 
> What is so great in this info ???
> 
> I do not see any useful usage of it

Yeah, it's pretty esoteric.  I'll explain in more detail later, but basicaly
it's valueable if your are writing a FieldCursor class as described in
earlier emails.  As it turns out I've decided to write a hierarchy of
subclasses of FieldCursor that parallels the subclases of Vfield, for a
variety of reasons including execution performance.  But if I had wanted to
write it all into a single class and not make a lot of subclasses, having
this would be quite useful.

I'll explain later in detail if you'd like.

In fact, I'll probably publish, or send you to publish, the FieldCursor
class hierarchy to use as a V4RB add-on or to include as an example.  It
essentially provides the lazy read feature in code until such time as you
get around to adding it V4RB.  If I didn't have a way to do this I would be
willing to move nearly as much code over to V4RB and feel ok about burning
bridges behind myself.  Or I'd have to restructure my use of the database in
a far more painful way to manage.

Later!
--Ed