Hello everyone,
Microsoft is once again testing my patience it seems

My problem is that
the 32-bit Access driver can't handle anything but basic ASCII paths, and trying to teach people to avoid those is a fruitless effort. So I thought I'll just find a workaround - how hard could it be?
As it turns out, the combination of
Windows + Access databases on network drives is very resistant to workarounds. Here's what I've tried so far:
Q: Escape the paths!A: I couldn't find any documentation stating that this is even supported by the ODBC Access driver, and had no luck with the standard approaches I tried (URL encoding, e.g.
"Gerät" → "Ger%C3%A4t", backslashes w/ hexadecimal Unicode code points). The driver also struggles with UNC paths,
even though they explicitly allow codepoints below 0xFF except for "*+,/:;<=>?[\]| which would suffice for the German special characters (
ÄÖÜäöüß) I'd have to handle.
Q: Create a temporary symbolic link!A: Windows considers symbolic links a security risk, and so you'll need admin permissions to create them, which my application doesn't have.
Q: Create a temporary hard link!A: The relevant files mostly reside on network drives, meaning that any hard link would have to be created on there as well. But there's no general writable directory for temporary files (like
C:\temp or
C:\Users\Khrys\Local\Temp), so it wouldn't be doable anyways.
NTFS directory junctions (or reparse points in general) also don't support jumps between volumes, so this is out of the question too.
Q: Just cd to the file's location and use a relative path!A: This would already be a very hacky solution at best, but the Access driver throws an additional wrench into the works here. I'd like to keep the scope of such global state changes as narrow as possible, ideally only while opening the connection (i.e.
pushd path/to/file && open_connection && popd - as an analogy, it's not a CLI tool) because after all, paths ideally only serve to tell the OS where to find some resource initially and from then on it's all handles / file descriptors, right?
But the Access driver refuses to work in strange ways after restoring the old PWD, even if "primed" by executing some data-accessing SQL statement right after opening the connection, so unfortunately this ain't it either.
Q: Just create a temporary copy of the file and move it back after you're done!A: The program I'm writing is an auxiliary tool that's integrated into our main application, which keeps the database open during the entire runtime of my program, so in addition to being cumbersome this approach couldn't even work in the first place - it has to be the
actual file.
It drives me insane seeing how easily this could be solved using Unix-style symlinks, but the Gods on Mount Redmond (or Rainier, I suppose) won't listen to my pleas

I'm running out of ideas...
My hate of MS Access is ever-growing

Inability to install both the 32-bit and 64-bit driver at the same time (thus forcing new tools into 32 bit too because the legacy application requires it), a lobotomized SQL dialect, abysmal performance, a broken driver that causes GDB to crash when debugging from Lazarus as soon as the application loses focus (???, also creates weird call stacks in the 5+ threads it spawns),
the sheer audacity to paywall the LONGINT data type behind a monthly subscription, unhelpful error messages ("optional feature not implemented" when attempting to use the aforementioned type)... I could go on and on.
