> Adam,
>
> This is obviously a "clean" test case. Likely in a clean database,

but more importantly, with table definitions that

Firstly, there is no such thing as a clean test case. A test case
will either reproduce the problem or not. If it does not, then there
are additional factors involved that must be included in the test
case.

It is a simple test case but then your instructions to reproduce it
were just as simple. To quote a pretty smart guy, Make everything as
simple as possible, but not simpler. If a more complex test case is
required to duplicate it, that is ok.

> were put into play. Just because the clean test fails is no

justification to drop it as -irreproducible-

>

Of course not, and I am not suggesting that. But if someone pushes a
bug report across my desk with a set of steps to replicate it, and I
follow those steps to the letter and the problem appears resolved,
then I file that report as fixed in latest version.

If the person who files the report is not happy, then the onus is on
them to adjust the steps to better explain the problem.

> I will track down when I made made these changes, and restore the

backup from before I made the type change. So long as

> it breaks again, I will file a bug report, with a test case.
>

Good.

Adam