title: Using .Seek, testing result, then .Seek again
body: <p>EDIT: HansUp's solution worked great, for anyone using this in the future make sure you drop your multiple indexes after you use them.  On tables the size of mine they were almost doubling the size of the database.  An even better idea I ended up using was creating a temporary db using the workspace object and preforming all the processing there, only bringing the final data back into the actual database.</p>
  
  <p>Hoping there is a way to do this, but I have not seen any way to control where <code>.Seek</code> starts looking in the index (other than using &lt; to start at the end).</p>
  
  <p>I need to compare 2 tables to find the originating record for a pay adjustment.  The issue is, in all their great planning the programmers for our SAP module decided to remove the unique record identifier from the output of the pay calculations, leaving me to reverse engineer where the adjustment has come from.</p>
  
  <p>I have been able to match most of the records using <code>.seek</code>, the issue arises when the result can be traced back to one of multiple records (they were forced to make dozens of corrective pay runs to fix errors in their original code).</p>
  
  <p>What I am hoping to do is use a <code>.seek</code>, test an adjustment variable (has the records pay been adjusted to 0 already) and if so, <code>.seek</code> again to the next matching record in the index.</p>
  
  <p>Is there a way to dictate where the <code>.seek</code> begins comparing index entries?  Can my subsequent search begin after the current match?</p>
  
  <p>I am aware I could use a <code>.FindNext</code> after the initial <code>.seek</code> but was hoping to avoid the <code>.find</code> group of methods due to their slower nature.</p>
  
  <p>Any ideas?</p>