Today I was developing a report that runs against our database. We want the reports to be able to be run from a few different WindowsNT machines, and ODBC looked a reasonable way of providing some location transparency.
“David”: did the obvious thing – went to the Windows Control Panel, clicked on the “Data Sources (ODBC)” icon and set up a data source. I then went to the Control Panel, clicked on the… ?
There was no Data Sources icon on my Control Panel. Nowhere. And so began a few fruitless hours of installing database drivers (DB2, Notus Lotes, and multiple versions of the Microsoft Data Access Components), ratting through the Windows Registry, searching both Google and MSDN, comparing my PC with David’s working one and, at length, inspecting directory listings for likely looking files.
After about two and a quarter hours, I found a whole bunch of “control panel applet” files in the System32 directory. They look like DLLs but have a .cpl extension. The missing “Data Sources (ODBC)” program was cunningly disguising itself as odbccp32.cpl, and I could run it by double clicking it. Woohoo!
That was enough to get me going, but I also wanted to know why the Control Panel applet was hidden. I Googled control panel cpl hidden. Paydirt. The top search result described a registry key named HKEY_CURRENT_USER\Control Panel\don’t load.
Firing up a registry editor, I deleted the odbccp32.cpl value from under the don’t load key, and the “Data Sources (ODBC)” icon magically reappeared in the control panel.
I could speculate on the reasons why such a key might exist, how many other such flippantly named keys might be in the registry, why my user profile was hiding the Data Sources icon (and Network Settings icon too!), or even how I might have tracked down the problem more quickly. But the big take home lesson was supplied by Charles when he suggested:
You really should write to Bill Gates and ask him when he’s going to get around to fixing Windows NT 4.0.
Comments
I'd settle for him fixing Windows XP, but he doesn't look like fixing *that* any time soon either.
If it's any consolation MS have silently admitted that the registry is crap by not using it as much in the new version of Windows. It still exists, but it's not used as much because they realised it was getting choked up.
If you compile a .NET project it creates a hidden file (ie: you have to use "dir /ah" to see it) that contains most of the stuff that would currently be found in the registry for that project. For the life of me I can't remember what the file is called, but trust me, it's there.
Found it: SystemVolumeInformation
It appears to be a directory, but it's actually just a file. It's like win.ini on steroids, on a per-project basis. It means that "installing an application" becomes "xcopy the project directory to the production machine". Don't have to modify the registry.
On ODBC: now that ADO.NET exists, it's the preferred technique for connecting to data sources. Importantly, you don't need to fool around with the OS to connect using ADO.NET, it's all handled within the .NET framework. I reckon that's going to make all the MCSAs pretty nervous.
2 hours eh? I've been wasting roughly 2 days trying to get Oracle Client working. What a bag of shite that is, especially the flakey DBAStudio(java).
And at no point has the registry been the problem.
Welcome To Computing.
Wasted time on windows!??!??!! I don't believe it.
Nice one, i had the same problem