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.
Précédent
Suivant
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement