Al-

>I think the best solution would be to modify the "little used DE form" so blank entries are no longer allowed.

Sorry. I thought that conclusion was obvious, but I see it wasn't. Yes, of course that's the solution. Since I only just finished finding the problem, no, it hasn't been done yet. This is a system that I "inherited" and there are tens of legacy problems like this. We work them out in a priority order sorted in and among other priorities that come up.

>Or have you already done this?

The client will now know what the situation is, and she has my recommendations. It'll be her call on how she wants to proceed.

>Or did you just remove the two blank rows? It's not clear)

That will be the immediate step, yes, until the data integrity is properly dealt with.

>The second best one would be to make your code more fault-tolerant so it would not matter if blank entries were present.

Hm. I disagree. Tables that have blank rows (possible) aren't normalized. The solution is in data logic, IMO.

>The third best one would be a check before you run your SQL, warning the user that blank records exist in the table in question and that the SQL results may not be as expected.

That's a kludge, IMO.

Just a note, I don't really want to digress too far from the point I was really interested in making. That is, it's usually dangerous to settle on a solution that *seems* to make the problem go away.