A windsurfing, CSS-grudging, IE-hating, web-developing, gigantic-machine-puzzling blog

Category: Windows 7

MS Access ODBC with Windows 7 64-bit and Perl

MS Access ODBC 64-bit Windows 7 driverJust writing that headline’s enough to make me cringe. Hell, I almost gave up at the thought of dealing with the ODBC error in the first place:

Can't connect to Access database: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified (SQL-IM002) at [script name] line [line number].

But turns out it’s not so bad, just a little tricky.

An important detail: I’m using Strawberry Perl 64-bit. It’s v5.12.3 multi-thread, but that doesn’t really matter. 64-bit OS, 64-bit Perl, 64-bit ODBC driver … don’t mix 64s with 32s & everything is good in the world. If you’re trying to use some twisted combination, this blog post may not be quite as helpful. But who knows? You’ll find out soon enough.

First step is make sure the MS Access 64-bit ODBC driver is present & functioning: Administrative Tools > Data Sources (ODBC), which brings up the ODBC Administrator. Switch to the Drivers tab to view the installed 64-bit drivers.

(Note to 32-bit-driver-on-64-bit-OS-type people: to see your installed 32-bit ODBC drivers, you’ll need to run the 32-bit ODBC Administrator instead. Tricky or what?)

My copy of Windows 7 only had the SQL Server ODBC driver listed. Head over to Microsoft’s website to download the MS Access 64-bit ODBC driver.

Once that’s installed, pull up your Data Sources window again & a bunch of new drivers will be listed on the Drivers tab. In my Perl program I’m using DBI, so I need the driver name exactly as it appears on the Drivers tab:

Microsoft Access Driver (*.mdb, *.accdb)

So in Perl-ese, that becomes:

use DBI;
my $dbh = DBI->connect('dbi:ODBC:driver=Microsoft Access Driver (*.mdb, *.accdb);dbq=[path to mdb file]') or die "\nCan't connect to Access database: " . $DBI::errstr;

Get the path right & it should work! Hope this helps someone.

Apache httpd.conf changes ignored in Windows 7

VirtualStore in Windows 7 causes problems

Feature? Hack? Or hugely misguided mistake?

Imagine this: You are a web developer. You buy a brand new computer running Windows 7. You install Apache using all the default installation options. You fire up your browser to see Apache’s “It works!” test page …so it does, Apache. Awesome.

You edit httpd.conf to point to your latest web project, restart Apache, refresh the browser. Which still shows It works! … not your project. Hmm. No startup errors in the Apache error.log …. you close & reopen httpd.conf & your changes still look good. Apache still shows It works! In a mad rage you delete all settings in httpd.conf & bang out some undocumented 4-letter profanity settings guaranteed to throw Apache startup errors. Restart Apache. It works! No, Apache, it doesn’t!! What the fuck.

WTF is happening is a little-known feature, hack, & extremely bad idea from Microsoft in Windows 7 (and some other versions) called VirtualStore. VirtualStore should have been called VirtualStoreYourFilesElsewhereAndNotTellYou, because that’s what is occurring.

When you saved your edited httpd.conf file, Windows 7 secretly saved it in (deep breath) …

/Users/[Your User Name]/AppData/Local/VirtualStore/Program Files/Apache Software Foundation/Apache2.2/conf/httpd.conf

… and a hidden link gets created within your Program Files folders to the VirtualStore copy. Normally this works okay with legacy Windows programs, but apparently with Apache running as a service, it doesn’t pick up the VirtualStore link.

The upshot is while you continue madly editing your VirtualStore’d httpd.conf, Apache continues reading the original, which you are secretly being prevented from editing. How are you supposed to know what’s going on? Take a look …

Awful VirtualStore Warning

Microsoft's alert that VirtualStore files exist

Yea. One little icon in the action bar. Not at all noticeable.

(Microsoft should consider using my patented red oval).

No indication of which files are “Compatibility Files”.

And apparently, the linked file system doesn’t work consistently. What a stupid feature. It’s a hack, really, trying to blindly protect an operating system infamous for core-level security flaws.

How about a simple warning that the VirtualStore hack was occurring? Or ditch VirtualStore & display a UAC-style dialog, “Program X wants to write to Program Files, cancel or allow?” Even cancel or allow would be an improvement.

run as Administrator

Don't forget this minor detail.

What triggered VirtualStore in the first place? Way back when you fired up your text editor, you needed to run it in Administrator mode. Only then does it have the ability to save files directly under the protected Program Files folder structure without VirtualStore links.

How to fix the VirtualStore mess — First, move your Apache config file(s) out of the VirtualStore folder structure. Then delete the Virtualstore/Apache Software Foundation/ folder. That removes the “Compatibility Files” links from the real directory. Then you can run your text editor in Administrator mode & redo your Apache config edits.

Or even better: right-click on the folder that contains the files you want to edit, click Properties, Security tab & give Full Access privileges to your Windows user.

Notepad (& possibly Wordpad) won’t trigger VirtualStore — instead they’ll simply throw a “permission denied” error until you switch to Administrator mode. Most third-party editors like Komodo Edit will silently generate the VirtualStore’d copies until you run them in Administrator mode.

You can see which of your applications are being VirtualStore’d by opening Task manager, Processes tab, View menu, “Select Columns…”, check Virtualization. Back at the task list, any process with “Enabled” in the column means you’re in for some VirtualStore fuckedupedness.

Best part: VirtualStore isn’t just for files — any program attempting to write to the registry under the HKEY_LOCAL_MACHINE\Software branch will be VirtualStore-slapped over to HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software

Hope this helps someone! As someone commented on another blog, “I really hate how Microsoft surprises you with their new retarded ways of keeping us safe from ourselves.” Amen to that.

If you have Windows 7 Professional, Ultimate, or Enterprise editions, you can disable VirtualStore completely through the Local Policy Editor. This may prevent some legacy programs from running, however.

For more, see VirtualStore is horrible. How do you disable it in Windows 7.

Powered by WordPress & Theme by Anders Norén