SOCI doesn't compile when using the UNICODE flag on Windows

[Krzmbrzl]

When defining the UNICODE preprocessor flag when compiling on Windows, SOCI fails to compile. The reason being that this flag causes functions calls to the Windows API that don't explicitly use the A (Ansi) or W (wide-string, aka: "unicode") flavor to switch to the latter and SOCI seems to expect to use the former.

I guess the easiest fix would be to simply be explicit about using the A variants of functions such as LoadLibrary (LoadLibraryA).

However, this wouldn't account for everything as e.g. ODBC seems to also take this setting into account causing it to use SQLWCHAR instead of SQLCHAR which then causes further compile errors.
Maybe explicitly un-defining UNICODE in the affected source files might be enough to revert back to normal behavior?

Another option would be to make SOCI itself adapt this "unicode"-weirdness (on Windows) and switch to wide-charracter representations. However, I think this is probably the least desirable way forward 👀

[vadz]

Why do you need to compile SOCI itself with UNICODE defined? Note that you can compile the application including SOCI headers with it being define just fine, of course.

[Krzmbrzl]

I tried undefining UNICODE for the SOCI part but got redefinition errors of some Windows API functions - I'm using static linkage. Maybe I need only refine my approach to make things work though 👀

In any case I was wondering whether it would make sense for SOCI to deal with this somehow - even if it is only a check whether this macro is defined and emitting an error stating that compiling SOCI with UNICODE is not supported. That'd already make things easier for downstream users as they don't have to wonder where that compile error is coming from.

[vadz]

FWIW I agree that the simplest fix would be to use A variants of all A/W functions and hope that everybody uses UTF-8, which should work on all non-ancient Windows systems.

[bold84]

#1041

This should solve the problem.