RSS access restored

We upgraded database hardware and software today in a long-anticipated (at least around here) move. To our surprise, that broke our new RSS feature – the code that exports the authentication information to the server had some pathname dependencies that we didn’t realize.

We’ve restored the RSS access, but we’re not sure we’ve fixed the systemic problem. We know how to fix it by hand, though, so you may see intermittent RSS access problems for the next day or so. They shouldn’t last more than a few minutes when they pop up, and we should have it fixed by the end of the week.

Update: Fixed for good now. For future reference, don’t store characters like linefeeds as literal strings – construct them from constants so that when you cut and paste things, helpful applications don’t convert them to returns for you.

Also, just because this ought to be easier to find on the Web than it is: You can’t use AppleScript’s “read” and “write” commands in Standard Additions inside an AppleScript in a FileMaker Pro script step. It’s because “read” and “write” conflict with FileMaker’s own terminology, so trying to use them gives you a syntax error and FileMaker won’t compile the script.

The workaround? Use the raw event codes. Instead of “read”, use <<event rdwrread>>, and instead of “write” use <<event readwrit>>, where << and >> are chevrons (option- and option-| on US keyboards). Note, however, that if you try this in Script Editor or Script Debugger, it will tokenize and decompile it to the terms “read” and “write” again, so pasting it back into FileMaker will break the script again. We keep the event codes in a nearby comment so we can paste them back into the right place when updating FileMaker’s version of the script. Now you know.

Update 2: Although no one outside the office should have seen it, the system to export subscription charges into our bookkeeping program didn’t survive the upgrade – it relied on several global fields in FileMaker Pro, and as we found out the hard way, clients can change global fields but their changes are never ever saved to disk. FileMaker’s own documentation tries really hard to say this but never quite manages to make it understandable. We had to rewrite some 10-year-old logic for keeping track of authorization batches, but with just a tiny bit of help, we got it done in a few hours.

(Note #1: I only ate two of the five. They don’t taste very good, but they work.)

(Note #2: Today is apparently SysAdmin Appreciation Day. As the SysAdmin, I appreciate that most of this is now done.)

(Note #3: We’re going to get a couple of really good articles out of all this, I’m told, but not about most of these details.)