-- Original post --
Many posts in this blog have pointers to work done by other families. For the most part, these were links right into an area of a database (via ID). Of course, that is not considered proper if one wants persistence. Why? As databases update, IDs can be re-assigned. Not always, but often enough so that following the link does not show what is expected.
Here is an example via images. The fix, which is a simple re-fresh of the search, is easy; the purpose of this post is to document the method. The example relates to an ancestor of the John Lowell Gardners.
The descendants list on the right was what was expected from picking the link. What came up was on the left. In the past, the blogger has been going back to update pointers when he runs across one of these ID changes. However, as we go along, we get more and more pointers. It's time to make a more permanent, and maintainable, edit. The newer pointers will have a new format; progress in the edit will be seen from the older pointers disappearing (no expected time for completion of the task).
In the meantime, here is how to recover the information (via ID) for the person for whom we have a pointer, assuming that they have not been removed from the database.
To set the context, see this page and look at son, Henry, and his wife, Jane. There were three descendants lists (different researchers) offered in the post: Standish, Dowling and Larson. In this case, it was the last one that had changed. The context tells what we're looking to see, namely Henry and Jane. If that does not appear, the first step is to go to Index and search.
The format is "lastname, first name" and will bring up a list starting with that name (or something close if the exact name is not found). So, in this case, we know that Henry was born about 1651. He's the second on this particular list. Pick the person to get the related page.
Now, across the page is a menu for Index, Descendancy, Pedigree, etc. The Pedigree chart is shown in many cases when the pointer is selected.
This is the text format. There is also a table format which is selected by a toggle. Above, there are a couple examples of the descendants list.
Now, the new format will include the database name, the person, and the birth year. That would allow search, plus help filter as, for any name, there can be many people. If the birth year is not known, there'll be the death year. If neither is known, we'll look for some other piece of information to distinguish the person.
Here is the pointer for John Lowell Gardner (Larson, b 1804). And, the pedigree showing Henry Lunt.
06/25,26/2014 -- rootsweb is back. Listing of 303 trees for Thomas (those with sources, showing descendants and providing the death year). ... Of the 303, 181 trees have parents for Thomas. ... Then, there are 43 trees with George being the grandfather of Thomas. ... See Whence came ...
04/08/2014 -- Today, the behavior of rootsweb is different than it has been until now. Yesterday, it was still allowing access to "world connect" page via the cgi-bin method. Is the change observed today permanent? The rootsweb status page says that there is a problem (does not give a time for fixing - also, points to Chrome and IE - says that Firefox is working - nope! - as well, Sea Monkey shows the same behavior). What does that tell us? In any case, the discussion of this post is now on the table again. Apologies are offered, in advance, for pointers embedded throughout the blog that, when picked, will cause the session to be directed to the ancestry.com site.
01/10/2013 -- The Bevan database was updated on 01/05/2013 which pushed pointers around (one of the risks of the rootsweb method). Will take awhile to follow all of these - the correction requires a simple adjustment of the pointer by 10s or a little more.
04/17/2012 -- This exercise will end up with a standard pointer that is more persistent than what we've used so far. We'll post the resulting formatted pointer here.