SQL Server timeout errors when using ADO
I work with databases of moderate size (a few hundred thousand records in a dozen or so tables, maybe 500 MB on disk.) I’m running against SQL Server 2000, which is supposedly an enterprise grade database. By the standards of Big Databases, this is pretty small potatoes, so it’s always a shock when SQL Server barfs. Sporadically, queries will fail with the following error:
Exception occured in Microsoft OLE DB Provider for SQL Server, Timeout expired. (8004e31)
(For your Googling pleasure I’m leaving “occurred” spelled wrong just like it is in the actual error message. The other thing to clarify here is the error number is actually a normal hex error code (0x80040E31) despite having been formatted to look like some wack-ass form of scientific notation.)
So most of the the Google hits on this topic yield various SQL cognoscenti telling various SQL newbies that their queries are lame, their network connection is bad, they should grow up and add an index to the table etc. Sometimes this is even valid advice.
But in some cases you just have a query that takes a Really Long Time To Execute. (Example: adding a new column with a default value to a table that contains 300,000 rows.) Queries like this run fine (if slowly) from the SQL Query Analyzer (which uses…ODBC!), but tank when called via ADO even if you set the Connection.Timeout property to 0 (= no timeout.)
Maddeningly more difficult to debug is that SQL Server occasionally stops answering queries for seconds(?) minutes(?) while it rearranges its sock drawer. I usually hear about this when one of my systems emails me an error log. In this case, it is not the query itself but SQL Server’s internal maintenance needs that cause the problem. The exact same query done a few minutes earlier or later would execute just fine. Since you never know when this is going to happen, you need to prevent the query from timing out after 30 seconds, which is the default.
It was thus nice to find DavidJ’s blog entry that reminded me that an ADO connection has both a Connection.ConnectionTimeout property (which I’ve been setting to increasingly huge numbers with no useful effect) and a Connection.CommandTimeout property. You need to set both of these to high values to avoid a timeout. So, in this case, the problem is ADO’s fault, not SQL Server’s fault. That means I can defer my rants about SQL Server to another day!
You can set these timeouts to 0 to indicate no timeout, but that’s bit dangerous since in some cases your timeout is actually is the result of a broken network connection and a timeout is desirable.
Syncing a Treo 650 with Microsoft Entourage
Well this is pretty lame for a “first blog entry in two years” but you gotta start somewhere.
I dropped my Kyocera 7135 and it landed on the antenna, after which I got no signal. Taking a look inside it was clear that the RF connector had broken off, so I resoldered it.
Unfortunately after repair reception was still poor. Presumably the antenna itself was damaged (you can see the bend in it above) or the phone had suffered internal injuries.
One can buy aftermarket antennas on Ebay for $10 but since I have total equipment coverage I took it to the Verizon store to get a new antenna there. It turns out the phone is old enough that they don’t support it anymore so they just gave me a new Treo 650.
This is good and bad. In many ways the Treo 650 is generally a much better unit than the Kyocera 7135. (It’s certainly a vastly more capable wireless PDA; for example it is actually possible to surf the web using this phone.) It also a camera and all the other spiffy features of today’s gadgets.
Still, there are a few things I miss from the 7135.
* The flip phone! I don’t know what manufacturers have against flip phones; it’s the best way to protect the screen, prevent random calls, and answer a ringing phone.
* The 7135’s LCD status panel. This was on all the time. It shows time, battery, signal quality, and Caller ID when a call comes in. Brilliant! The Treo’s main screen is beautiful (much, much better than the 7135’s) but it sucks a lot of power so it’s rarely ever on. Instead you just get this blinking LED that tells you, well, I haven’t figured out what it tells you yet. I miss my secondary display.
* Ruggedness. Despite me having busted the 7135, I have to admit I have dropped that sucker a bunch of times. I think it only died because of the peculiarly bad manner in which it fell. It was a solid phone.
* The 7135 can recharge while plugged into your computer. For some dorky reason the Treo 650 doesn’t seem to recharge when plugged into a computer even though the USB cable feeds the power connection. I guess I need to be one of the cool kids and use Bluetooth to sync the phone.
I don’t miss the Kyo’s sluggish response, the random delays that made it seem like the keypad was broken, or the totally, completely useless email functionality.
Anyway, the real reason I am writing this blog entry is that I had trouble syncing my phone with Microsoft Entourage, and now that I have it working I figured I should document it.
Start with this page at Treo Central. It has some good hints.
Here’s what I had to do:
* I am running OS X 10.3.9, Entourage 2004 version 11.2.1.
* Start with a clean, empty phone. See mytreo.net for instructions on nuking your phone.
* Clean up your local Palm folder (in ~/Documents) by creating an archive (.zip) and deleting the one you have. (If you have any actual palm apps, save them somewhere else and defer loading them until the sync is working.) In my case, the first time I synced the phone I ended up loading the Treo 650 with all kinds of Kyocera-specific code. Not good.
* Back up your Entourage data in case something horrible happens.
* The PalmOne installer seems to be incapable of finding your old Palm software, so it installs new Palm software in a subtly different location and you end up with two palm desktops, two hotsync managers, etc., all with the same name. To avoid this, backup and nuke your old /Applications/Palm folder.
* Install the software provided by PlamOne with your Treo.
* Run the Handheld Sync Installer (Applications/Microsoft Office 2004). This will move Entourage-incompatible conduits from /Library/Application Support/Palm Hotsync/Conduits/ to /Disabled Conduits. (Note to Palm tech writers: I would be nice if you’d mention where the conduits live somewhere in your documentation.) Say yes to everything.
* Run the hotsync manager. Edit conduit settings. Open Entourage conduit. Click the mysterious “Enable synchronization with these new handhelds” box. I could not make it work without this box.
* Log out and back in again for the hell of it.
* Press the sync button.
Once all of your synchronization stuff is working you can start bringing over your Palm applications.
Case-Insensitive Tab Completion in bash (default OS X shell)
I’ve been wanting case-insensitive tab completion from the shell for about 2.2 years. Ignore all the stuff in the man page about “nocase-glob”, which I guess affects how globs like Honig* operate. Instead, you want to do this:
- create file .inputrc
- set completion-ignore-case On
- save file
Kill your terminal window and open a new one. From now on, when you hit tab, filenames will expand in a case-insensitive manner. (Since HFS is case-insensitive anyway, this makes a lot more sense.)