Use What You Already Know: "Drive" Qlikview QVD's from Excel

Leverage tools you already know how to use. That should be maxim one for decking out one's analytics toolbox.  (It's more important than any single piece of advice from usability specialist Jacob Nielsen). An example of this principle is the product Vizubi.  Vizubi provides an Excel front end to Qlikview's highly optimized and super-efficient native "database" structure, a QVD.

I haven't tried it, and have read no reviews of it, but it has one laudable feature.  It leverages a tool for which skillsets are abundant:  Excel.  It has other reported capabilities, such as natively understanding what to do with time variables, and itself using in-memory resources, but that one feature may be worth the price of admission.

The idea of using Excel as a front-end has a time-honored tradition (e.g., Arbor Software's Essbase).  It's no accident.

Discovered: Source of Mysterious Musical non-POST Beeps

It's emblematic of how far we haven't come: signalling computer system problems with beeps instead of intelligible messages.

Yes, I know the excuse - no UI, compatibility with older hardware, and so on. But consider this brief story.

Take a Windows XP machine with Intel D865GBF motherboard. Running fine since 2006. The plan is to convert the boot disk to RAID 1. An existing controller already running in the machine was suitable for the task. Its firmware was out of date and incompatible with the Windows-based "PAM" management tool for the controller. The firmware was updated, the PAM applications and Windows driver to accompany moving from JBOD to RAID 1. The drives were updated to RAID 1 and files restored to it preliminary to making it the boot disk.

Windows booted fine from the old boot disk. After about two minutes, a repeated low - high beep pattern began - using a perfect fourth or fifth. No POST codes matched this symptom. The Intel desktop tools showed nothing out of the ordinary with power levels, temperature or fan settings. The pattern was ceaseless. Some POST codes seemed somewhat plausible, suggesting that the CPU detected a problem with itself, but under light test the O.S. behaved well except for the beeping. The system was rebooted and memory tests run for an hour. No errors were detected.

After much investigation and fruitless web searches, the culprit, if it can be called that, turned out to be the presence of the Promise TX2300 controller, which had been in the system for years. When it was removed, the beeping stopped. The ultimate cause is unclear - possibly there was an indirect consequence of changing to RAID 1, but there were no messages anywhere, not in the event log or in the directory where the Promise driver was installed.

The absurdity of troubleshooting beeps with the full Windows UI present should not be lost on anyone.