Re: open sqilite path unicode (SQLITE_WIN32_HAS_WIDE means unicode)

[Anonymous Monk]

I would first check without GetANSIPathName...

https://metacpan.org/source/ISHIGAKI/DBD-SQLite-1.40/lib/DBD/SQLite.pm

    # To avoid unicode and long file name problems on Windows,
    # convert to the shortname if the file (or parent directory) exist
+s.
    if ( $^O =~ /MSWin32/ and $real ne ':memory:' and $real ne '') {
        require Win32;
        require File::Basename;
        my ($file, $dir, $suffix) = File::Basename::fileparse($real);
        my $short = Win32::GetShortPathName($real);
        if ( $short && -f $short ) {
            # Existing files will work directly.
            $real = $short;
        } elsif ( -d $dir ) {
            # We are creating a new file.
            # Does the directory it's in at least exist?
            $real = join '', grep { defined } Win32::GetShortPathName(
+$dir), $file, $suffix;
        } else {
            # SQLite can't do mkpath anyway.
            # So let it go through as it and fail.
        }
    }

Although according to https://metacpan.org/source/ISHIGAKI/DBD-SQLite-1.40/sqlite3.c unicode filenames should work

#if SQLITE_OS_WINCE || SQLITE_OS_WINNT || SQLITE_OS_WINRT
#  define SQLITE_WIN32_HAS_WIDE
#endif

but there doesn't appear to be a test in the (perl) test suite

So maybe your version is too old, you're getting 8.3 filename interference, maybe your copy of DBD::SQLite was compiled without SQLITE_WIN32_HAS_WIDE or or something else entirely :)

These things (above) are the things I would check

I would also read read Win32::Unicode and Win32::Unicode::Native and Re: dos path accents and read Re^5: threads::shared seems to kill performance (Workaround). and beware of :memory: and Windows Alternate Data Streams