>>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.
>
>Thanks for confirming you're fixing the form, not just deleting the blank records which is how I first read it. I only suggested #'s 2 and 3 if for some reason #1 was impossible; I've had to do either or both on occasion depending on business circumstances but, they're not my first choice ;-)

Again, I'm really hoping to generate a discussion of the principle, but to ease your anxiety < gd&r > and because it touches on another issue I've become interested in, the entire entity and how it's used in the system is up for review. When we delved into its relationship in another area, my client discovered she wanted to change things quite a bit, and so is working out her requirements for it. So, the idea is what and when do you change a module in a system, even one that has bugs in it? The answer is _highly_ dependent on the client and their needs, of course. In this case, we don't touch something til we've thought through the objective and clearly defined the goals, prototyped, programmed, tested (I use an independent tester, Kurt Hohmann for this).