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