Re: unload creating duplicate versions of edited records

> Not necessarily, it would also happen if the query were using an index and > that index key was being modified by some users so that the row shows up > again as the unload follows the btree. > hold the phone; a plain unload doesn't follow indexes; do you have a WHERE clause on the unload? Regardless of whether the rows are drifting in the index or "in-place alter" effects are kicking in, all that's said so far is relevant. PS - when I say "in-place alter" I mean an effect where .... well, the easiest thing to do would be to read about it in the "Altering a table definition" section of the "Performance guide for Informix Dynamic Server". It's what can happen when you issue an ALTER TABLE command.

On Oct 20, 3:04 pm, Andrew Clarke <acla...@civica.com.au> wrote: > > Not necessarily, it would also happen if the query were using an index and > > that index key was being modified by some users so that the row shows up > > again as the unload follows the btree. > > hold the phone; a plain unload doesn't follow indexes; do you have a WHERE > clause on the unload? > Yes, There is a "WHERE". See above where I posted the unload.

> On Oct 20, 3:04?pm, Andrew Clarke <acla...@civica.com.au> wrote: > > > Not necessarily, it would also happen if the query were using an index > > > and that index key was being modified by some users so that the row > > > shows up again as the unload follows the btree. > > > > hold the phone; a plain unload doesn't follow indexes; do you have a > > WHERE clause on the unload? > > Yes, > > There is a "WHERE". See above where I posted the unload. > oh yeah, there it is. So row drift in the index is a good candidate. This doesn't matter too much though, the mechanism of the cause won't affect the solution.