Steffen Goeldner wrote:
>
> I understand your objections because each (but the first)
> retrieval is based on a 'current record' - thus storing
> that state in a separate iterator object may be a better
> choice.

I rejected that! The documentation says:

  Btrieve initializes the Position Block when your application
  performs the Open operation, then references and updates it
  during file operations. Therefore, your application must
  specify the same Position Block on all subsequent Btrieve
  operations for the file.

Thus a Position Block is like a file descriptor. The difference
is that it allows index-sequential (in addition to sequential)
access and bidirectional navigation.
The best I can do is to store it (and a few other state variables)
in a BTRIEVE::File object. Btrieve operations can then be called as
methods on that object, e.g.:

  my $B = BTRIEVE::File->Open('TEST.BTR');

  for ( $B->StepFirst; $B->IsOk; $B->StepNext ) {
    print $B->{Data}
  }

  $B->{Key} = 123;

  for ( $B->GetEqual; $B->IsOk; $B->GetPrevious ) {
    print $B->{Data}
  }
  for ( $B->GetGreater; $B->IsOk; $B->StepPrevious ) {
    print $B->{Data}
  }

That's much easier to use than BTRIEVE::Native and still close
to the original API a Btrieve user is familar with.

I'm still open for namespace suggestions. The following list

  BTRIEVE::File
  BTRIEVE::ISAM::File
  BTRIEVE::ISAMFile
  BTRIEVE::IsamFile

with descending preference comes into my mind.


Steffen

Reply via email to