A member named Kent wishes his first name was Clark and he could fly around the world to reverse time in this True Domino Blooper.
We've all had it and we all hate it -- that "I know I'm forgetting something" feeling. When SearchDomino.com member Kent K. made a list to give to his company's Domino ISP concerning the migration of the site's database from Domino R5 on Windows NT to Domino 6 on Linux, he had that same sinking feeling in the pit of his stomach.
Turns out Kent's stomach was right. While he had included fixing case sensitivity on file names when used in links and agents, changing connection documents and changing FTP login parameters, Kent forgot to tell the ISP that the main database was encrypted using the old server ID file and that they had to decrypt it first on the old server before moving to the new one.
So the migration was made with the omission, and Kent went to test the site on the new server, only to get an error message from Domino telling him the database was inaccessible due to local security. Remembering that he had failed to mention the decrypting issue, Kent told the people at the ISP, but they could not change the encryption setting back to "Do not encrypt," as the migration already took place. As Kent writes, "I suspect that if I had done it with the same ID that performed the encryption it would have been successful." The ISP workers put their brains together and came up with a workaround: They created a database copy to the new server. The site came up fine and everyone was happy.
But not for long, or this wouldn't be a very worthy blooper.
Later that day, Kent was hunting through the database and found that several thousand very important documents were missing -- order forms from 1998 to the present. In trying to find the reason these docs weren't added to the new database copy, Kent saw a Readers field on the form that excludes the ISP's server names. This setting was originally put into action so that the ISP's servers could not read the sensitive data (often containing credit card numbers) in the documents created by this form. However, because the Readers field contained Kent's server and user names, the documents were replicated and visible to Kent. Anyone outside Kent's company, however, could not read these documents as a result of this security measure.
When the ISP created the copy of the database using File --> Database --> Copy, these secured documents (while not being readable to the new server's ID file) were not added to the new database copy. Therefore, the replica on the company's staging server that was made from the copy from the ISP's server did not include the documents because they didn't exist as far as the ISP was concerned.
Alas, Kent had thought ahead before the whole migration -- he had a pre-port database replica on a backup staging server and recovered the "hidden" docs by copying and pasting them to the new copy, although the @Created date got a bit muffled in the process. To fix this, Kent and his team captured the creation date in a computed When Composed field and performed a bit of view formula magic.
You can bet that the next time Kent has to worry about a server upgrade, he'll be sure to have Clark Kent or Lois Lane on his team to help him out.
Do you have your own blooper? Send it in and claim your fame.
Every story in our bloopers series comes to us directly from a SearchDomino.com administrator, developer or consultant. For obvious reasons, some contributors choose to remain anonymous.
MORE ON THIS TOPIC:
Read all SearchDomino.com's true bloopers.
View our Best Web Links on Domino/Notes administration.
