Use of the SUBST command to reduce breakage of Microsoft Access 2003 links - an esoteric hack for escaping DOS 2.1's "path trap".

Where to pass on these kinds of tips and techniques for working around Microsoft's kludgy applications? It's a bit of a puzzle since Microsoft's products have an unlimited number of oddities requiring an unlimited number of hacks. This is but one of the myriad ...

I posted this one to Microsoft's high quality Access queries newsgroup, and since I use this blog to keep track of things like myself I'll post it here too. It's probably too esoteric for anyone else though ...

Use of the SUBST command to reduce breakage of Access links

One of the great failings of the past 20 years of Microsoft's dominance has been the failure to implement good file system redirection. XP today is almost as dependent on absolute paths as it DOS 2.1. [1]

In the world of Access this manifests as broken links to external data sources. I use links very extensively in my data management work, a typical project may contains dozens of query files with links to dozens of data tables distributed over one or more drives. Any change to any path, including renaming a folder or file or moving a file, will break the links.

Access 2003 responds to a broken link by irreversibly breaking a query on first use. It doesn't matter if you don't save the query when you see it's broken, the query is now broken. (This may be fixed in 2007.) If you're careful you can use Linked Table Manager to repair the link before first use of the query, but if you foget you're in trouble.

Today I reinvented a workaround. I say reinvented because I found a single mention of it in this newsgroup from 1999 [2]. It worked then so I presume it works now. Seven years is long enough that I'll repost the technique.

The trick is that DOS 3.x's SUBST command still works in XP. Indeed, in XP you can apply a SUBST operation to path containing a drive letter mapped to a network share.

The result is a de facto partial indirection layer.

Assume I have a database file john.mdb in c:\work\fark\dbase\cpt.

I run this command: SUBST P: c:\work\fark\dbase\cpt.

Now I create a link from a query database to a file in john.mdb

The link will have the path P:\john.mdb

Now I move john.mdb to e:\dbase\cpt

I now clear the P: substitution and run: SUBST P: e:\dbase\cpt
my links will not break.

For more information on SUBST simply type SUBST /? on the command line.

Of course if Microsoft were to implement file system indirection, or even relative paths in Access links, this kludge would not be useful.

meta: jfaughnan, jgfaughnan, Microsoft Access 2003, indirection, redirection, link, linked table manager, 070620

[1] Mac Classic's greatest innovation was an absolute file identifier that provided indirection, one could move files around without breaking relationships. OS X, sadly, broke much of this, but OS X today still has quite a bit of indirection.

Indirection is a member of the interesting class of things that are as unappreciated as they are valuable. Nobody ever mentions file system indirection as the most important innovation of the early Macintosh, but I think it really was. Twenty years later XP is almost as much a "prisoner of the path" as DOS 2.1. Sadly, OS X has regressed, though it's still well ahead of XP.

Despite the nastiness of using a fully specified path name to implement data table links in Microsoft Access, I do have to say the "link to table" technique is very useful and has very impressive performance and reliability.

The future of SVG is ?

I was an old SVG fan way about 3 DCB1 (before the Dot Com Bust 1). I'd lost track of it over the past few years as it was eclipsed by Flash and by Ajax based non-standard solutions. Work questions made me look it over again recently. Somewhat to my surprise, the technology may not be quite dead. So if Apple and Google decide to be nicer to each other than, say, Netscape and Sun @ 1997, we might see SVG play some role on small low bandwidth computing devices. Like, say, the iPhone.

But what about, you know, the IE web? On the one hand Microsoft's Silverlight is going to crush Adobe's Flash, so Apollo and Flash are irrelevant. Similarly SVG can't play on the larger web without Microsoft, so SVG seems irrelevant on the IE web too. On the other hand Google can't cede this battleground to Silverlight. (Apple of course can't either, but in this struggle they root from the sidelines).

So will Google buy Apollo/Flash (and/or Adobe)? Or will Google embed SVG support in the Google toolbar and thus bring it to IE / Vista? Or bet on both horses, since either is safer than Silverlight? (Adobe's SVG plug-in was never relevant, so let's not even mention it.)

This will be interesting to watch ...

If anyone sees evidence that Google is going to put an SVG reader into their toolbar code please send a note to jfaughnan@spamcop.net. I'm curious!

Gordon's Tech - migration to new domain

I've now migrated my three primary public blogs to the domain kateva.org. False alarm, I had some imaginary glitches and switched back to the old url for now. I'll probably switch again in a few weeks because it does actually work including automatic feed updating through the '301 redirect'. Below are some notes I'll leave in for reference ...

Update: Well, that didn't go so well after all. The feeds don't seem to follow the migration, so if you move a blog the old feeds don't seem to work. I'll see if I can get some Google tech support help, but in the past they've been hard to work with.

Update 6/20/07: I was too impatient. A post to Google Groups (I didn't try Google tech support) received a very kind response from "wasted":

I don't use bloglines myself, but Blogger will use a 301 redirect on the blogspot address to go to the new custom domain, for everything including feeds. So any feedreader should follow the redirect...

And so it does. It just takes a bit longer to update than usual, and it follows the common bloglines behavior of showing an unread count of "10". Bloglines updates the URL as well. I did two roundtrips on my test blog and it works. I've switched back to the old urls (hey, I was justifiably nervous) but I'll switch them one at a time over the next few days. It's noteworthy that bloglines managed two roundtrips, a "301 redirect" is "permanent". (see also)

Clearing the Finder "Open With" contextual menu

Delete com.apple.LaunchServices.plist. For more, see - Mac OS X: Clearing the Finder "Open With" contextual menu

How to create a google apps custom domain and move your blogger blogs to your new domain

Okay, I'm impressed.

This was a bit hard for me to figure out from Google's generic documentation [1], but with the way I've described the process below anyone can do it. Cost is $10/year. It took me about 30 minutes to:

1. create and register a custom domain (kateva.org) and set it up with free google apps.
2. create a CNAME entry corresponding to the name I want my blog to have.
   (Example: instead of http://googlefaughnan.blogspot.org this blog will eventually move to http://tech.kateva.org)
3. change my blog publish settings to the new url and demonstrate the new url works and the old one redirects.

I've done this for a test blog I created for this kind of experiment, but in the description below I'll use this blog as an example (though as of this posting I've not yet moved it).

Get your Google Apps domain and configure your subdomain CNAME settings.

1. Go to Google Apps and register a domain for $10/year configured with the free Google Apps services. (Same thing we do for our family email, I have a few businesses setup this way too.) In this case, I used kateva.org. (Kateva is our dog's name, I rather like it.)
2. From Google Apps follow the link on the advanced tab to eNom's configuration screens. (The advanced tab will give you a high security password and username information). Note there are host records associated already with ghs.google.com.
   
3. Click the edit button and add a new row. For "host name" enter the name of the blog, such as "tech" (for Gordon's Tech, which would then have the url http://tech.kateva.org). For Address use ghs.google.com. For Record Type use CNAME.
   

Now go to Blogger and select the blog you want to move.

1. Note the current blog URL, because when you're done it will be gone (but it will redirect).
   
2. Click on Publishing tab.
3. Enter the url corresponding to the CNAME you created (example: notes.kateva.org).
4. Don't use the missing files host. (This is mostly for persons who had FTP blogs and are switching to a hosted blog.)

Now test

1. Does old URL redirect?
2. Does new URL work?

I'm going to do some more testing with feeds and the like, then move my blogs. As to why I'm doing this, that will be a post on Gordon's Notes shortly ...

Two Blogger help files to use for reference:

• Using a custom domain
• Create a CNAME record for my custom domain?

[1] They're clearly trying to be "open" and "generic", but this works very easily if you do everything with Google. They just don't document it that way.

Update 6/18/07: I'm concerned that after one makes this switch, feeds that point to the old URL no longer update. I hope I'm wrong about this! I'll update as I learn more. Not good if true! (See also)

Update 7/19/07: It turns out that the 301 redirect works, but only at the domain level. Since Google changed the syntax for RSS feeds between their blospot and custom domain implementations RSS feeds don't "update" by redirect. Atom feed syntax is identical, so they do update. Google has not acknowledged nor documented this.

Also, it's interesting how this works. A CNAME is imply a redirect. So all requests for blog.kateva.org are redirected to ghs.google.com. I assume when one switches in Blogger to a "custom domain" Google creates a relationship in ghs.google.com so that all requests for the custom domain sent to ghs.google.com are resolved internally. So this solution implements two layers or indirection, one at the CNAME level and one at ghs.google.com.

Update 4/15/2008: Google never did fix the old-rss redirect bug.

The graveyard of minimized windows ...

When you use VR goggles with 30 foot wide virtual displays, you'll see where minimized Windows go ...

The Land of Wind, Ghosts and Minimised Windows

... So what modern Windows versions actually do when you minimise a window is move the window.

WinNT and its descendants - possibly even Vista, though I'm not sure - move minimised windows to the undisplayable location -32000, -32000. Way up there, eight to ten metres above and to the left of your monitor(s), all of your 'minimised' windows are hanging in the air.

Windows 95 and its descendants, though, couldn't go that far. They should have been able to, but too many programs - serious expensive commercial programs from companies that should have known better - went crazy when presented with large and/or negative window locations. Windows 95 had to work with as much existing software as possible, so (read all about it on Raymond's blog here) it ended up moving 'minimised' windows to only 3000, 3000.

The 3000, 3000 position stayed the same for the rest of the 95-derived Windows variants - Windows 95, 98, 98SE and ME. And it gives rise to an amusing artefact.

If you install one of those versions of Windows on a computer with two really humungous monitors (or three normal screens), and then tell Windows that the screens are positioned diagonally with the primary at the top left, you can see the Land of the Minimised Windows...

BTW, this is one of the things Apple's developers messed up when they semi-ported Safari to Windows.

The $20 noise reducing "headphone" solution that beats the $350 Bose QC 2 ...

Or so Pogue's readers claim: 

Blocking Out Background Noise - Pogue’s Posts - Technology - New York Times Blog

...As another reader put it: “I have a Bose QuietComfort 2 headset which transforms my daily commute into almost a recreational activity. But I’ve found a better solution: Get a pair of lightweight, industrial hearing protection ear muffs for no more than $20 by Bilsom. (I love these: http://tinyurl.com/2r4a6y).”

He then suggests that, for music, you can slip a pair of regular old iPod-style earbuds *inside* the earphones. “The sound reduction is superior, there are no batteries required, it is a much cheaper solution, and the sound can be stunning, depending on what brand of earphones you buy.”

(This reader offers a video that demonstrates a similar hack: http://www.marvgolden.com/hearing/index.htm.)

This is an over-the-ear effect similar to the in-ear high end occlusive earphones. It probably won't be as good at reducing continuous noise, but it will blunt outside conversation, music, etc. Depending on what you want, this could be an advantage or not.