|
This used to be required but it seems to me that it might not be, as of v17. I notice that the dblgen17 dlls are now embedded in the main assembly, and presumably extracted at runtime as needed. SO those don't have to be separately distributed, right? |
|
I don't know what you mean by 'dblgen17 dlls are now embedded in the main assembly'. Is that a .NET reference? If so, sorry, I cannot speak to that part of it. dbicu17.dll has always been "optional" to some extent but there are things you cannot do without it such as character set translation between two different multibyte character sets. On Windows we can sometimes fall back to OS character set translation routines if dbicu17.dll is not available but it can be rather inefficient. Character set conversion can be done on the client side in some cases. In fact, the ODBC driver tries to do that by default so that the CPU load of character set translation is distributed to the clients. FWIW, on the server side you also need dbicu17.dll for linguistic comparisons with SORTKEY/COMPARE and to use a database that with a UCA collation. Also not that if you need dbicu17.dll you also need dbicudt17.dll (if I remember the name correctly). There is at least one other file I can think of that help charset translation: sqlany.cvf (asa.cvf in old versions). It contains pre-build mappings for single-byte to single-byte translations. Thanks John (and Chris). Just FYI, yes, this is a .Net context. .Net assemblies (dlls) can embed additional resources, and Sap.Data.SqlANywhere.Core...dll does that, embedding the dblgen17.dll for runtime extraction as Chris mentioned.
(25 Aug, 10:08)
Leo Tohill
|
Only dbdataX.dll (or its equivalent on Linux) is embedded in the assembly and gets extracted to %temp%{guid}\dbdata17.dll. The remaining DLLs are loaded from the SQL Anywhere bin directory or other SQLA deployment location. The additional files are:
dbicu17.dll, dbicudt17.dll dblg[LL]17.dll dbrsa17.dll ( 17.0 build 2000 and newer)