LOCUS DEMENTIA

As one of my consulting services, I develop WMS9 server plugins. If any of you has ever tried to develop a plugin for the Microsoft Media Server, you know that there is very little documentation for it, and very little support. Recently, one of my clients setup a new Windows Server 2003 Enterprise system and tried to deploy our plugins to it. As you can imagine, the plugins did not work. While the other Micorosoft supplied plugins worked, my plugins reported error 0xc00d157d. You should try to google for that error code to see what you find. The WMS log console shows that my plugins are reporting a binding error, yet the popup error message reports that it's a .NET runtime version error. Which path to choose? For about a week, both me and my client's IT staff looked feverishly for a fix. Sometimes they blamed my code, sometimes we cursed Microsoft, and other times we looked to the heavens ala Google searching. Nothing seemed to work. When I tried using the fusion log viewer, an

I had morning coffee with a well respected friend of mine recently. Aside from chatting about the usual wifery and family, we touched on the subject of clustered indices and SQL Server performance. A common misconception in the software industry is that a clustered index will make your database queries faster. In fact, most cases will demonstrate the polar opposite of this assumption. The reason for this misconception is a misunderstanding of how the clustered index works in any database server. A clustered index is a node clustering of records that share a common index value. When you decide on an index strategy for your data, you must consider the range of data to be indexed. Remember back to your data structures classes and what you were taught about hashtable optimizations. A hashtable, which is another way of saying a database index, is just a table of N values that organizes a set of M records in quickly accessible lists that are of order L, where L is significantly less than M.