clearquest lessons
1. Syncs, epochs, oplogs, and multiple user accounts make my head hurt.
2. The directions SJ used to break the connection to production are missing the step to update the connection information (meaning if you try to launch CQ via the thick client or the web client, you point to PROD still) – chreplica isn’t sufficient on its own. The directions DH posted in eRooms include this information. You can update the connection info through the DB as DH recommends or through the Maintenance Tool. In my opinion, DH's method is easier and more reliable.
3. I’m not sure the restorereplica step SJ used is necessary. But it doesn’t hurt anything.
4. If you’re configuring a site to act as the ‘hub’ and it hasn’t been the ‘hub’, it will not have the right epochs for the remote sites. You need to get the epochs from the remote sites (ie, get the epochs EMCCQPA1 thinks it has for itself from EMCCQPA1) and change the epochs the new hub thinks it has for the remote site (ie, set the epochs EMCCQBANG1 thinks EMCCQPA1 has to match what is really on EMCCQPA1) or you get cryptic oplog errors on exports and the packet fails to ship.
5. If the receipt handler on a site doesn’t work when you first install, try uninstalling CC and CQ and reinstalling both. I don’t know why this sometimes happens, but it has fixed things for me every time that I can remember.
6. CQ is very sensitive to its DB sets and DB sets can be very sensitive the to the user. I could run the sync commands on BANG by hand and they would work. I could run the BAT file on BANG that the scheduled task executes and syncs would work. If I tried to execute the BAT file on BANG using the scheduled task, I got cryptic oplog errors. Somehow the account that was being used by the scheduled task (the albd account) was pulling a DB set profile from the registry that referenced PROD and not TEST. I changed the scheduled task’s account to be CQBatch and removed every DB set reference I could find from the Maintenance Tool and then the registry before re-adding the correct DB set and the scheduled task is working.
7. If you’ve just configured DBs in TEST to break the connection to PROD and packets are disappearing, something is *very* likely configured wrong. You have a typo; you didn’t commit the DB changes; you missed a change.
8. Running InSync-CQ in PROD and using CQMS commands for syncs in TEST provides an extra level of protection against accidentally ‘crossing’ PROD and TEST because they expect packets from different locations. I would recommend always using CQMS commands to get syncs rolling in TEST when you’ve just refreshed TEST from PROD even though InSync-CQ is simpler because it gives you this extra protection.
so bill and i went away for a couple days and mom puppysat. on our way home, i get a call from mom - there's a lot of snow, drive safe, the puppy is in, your mail is on the table, and oh, by the way, you have a bat in the house, love you, bye.