If (and only if) the <filepool> configuration option was in use, in some cases, a very simple loop (that scanned the table forward using READ NEXT on the primary key to delete records) failed because the second NEXT call (i.e. the NEXT call immediately after the DELETE) returned the wrong record. The logic has been corrected to eliminate this problem.