I couldn't have said it better. But I'd like to add that
*if* the information is really in two different *tables*,
then the design violates some of the most fundamental rules
of database design. I suspect that one or both are "views"
of the underlying tables - views can be altered without
altering the database structure.
Ruth Ann
"John B. Lisle" wrote:
>
> Michel,
>
> You are describing the implementation and accepting that a limitation in
> the implementation means that a feature is correct.
>
> What you are telling us is that the design of the program is going to make
> it more difficult to provide the function in a way that most users seem to
> want it implemented.
>
> If the product is implemented and performs as it is documented to perform,
> then it is not a bug. But it can be an enhancement request which is saying
> that there was a bug in the specification.
>
> If the product is implemented and does not perform as documented, then it
> is a bug.
>
> I think it is a bug. But, I do not know if the bug is in the
> implementation or in the specification.
>
> Unless most users would like it left as it is.
>
> john.
>
> At 04:39 PM 3/20/2002 -0500, Michel Lacoursiere wrote:
> > >I have alerted the test list. There is likely a bug here.
> >
> >There is no bug here. The Name List without the AKA comes from an Access
> >table which also contains Birth, Christ., Dead, Buried dates and places,
> >among other things, so it is possible to sort it by Birth Date.
> >
> >The Name List with AKA comes from a different Access table which doesn't
> >contain the Birth Date that's why when you use the option to "Include
> >Alternate Names" the Name List is not sorted by Birth Date but rather by
> >RIN.
> >
> >The way it is working now is intentional, no bug.
> >
To unsubscribe please visit: http://www.legacyfamilytree.com/LegacyLists.asp
Legacy User Group Etiquette guidelines can be found at:
http://www.LegacyFamilyTree.com/Etiquette.asp
