The following was discovered by another user. I have confirmed the result and I am reporting it here.
Suppose you are in the Edit Person screen and click the big + sign to add a fact. Suppose you filter the list for a fact that is not there. Filtering the list for the fact xxx should work nicely for the purpose, but filtering by any fact type that is not in the list should work nicely. Suppose you click OK to add the fact.
The fact will be added basically as a null fact. There will be no error message and RM8 does not refuse to add the fact. This seems wrong somehow or other. Curiously enough, the null fact can be edited and its fact type can be changed to a valid fact type. The null fact can also be deleted. But if the null fact were left in place for the person, there would never be a way to find it again except luck. It seems to me that RM8 should not enter a null fact into the database. I do wonder if perhaps this behavior is by design. But I hope it’s just a minor bug rather than an intention.
On a much more technical basis, I looked at such a null fact in the RM8 EventTable. It’s not really null. It does have a valid EventID and it has an OwnerID that links to the correct person. It also has a valid sort date.
But all the other fields are zero. In particular, the EventType is 0, which effectively is null because there is no corresponding fact type for an EventType of 0. In other words, there is a referential integrity failure if the fact is joined to the FactTypeTable. Running all the database tools does not identify that there is an error nor does it delete the null fact as a phantom record. I didn’t expect the database tools to identify or fix the problem, but I had to check it out.