Database fields now using unicode

[rjuli...@gmail.com]

Greetings, forum dwellers....

I am upgrading my code to VAST platform 2024,

and am running into a new issue.

I tracked it back to the new version of

AbtOdbcDatabaseManager class>>#buildTypeDict.

The String-related field types have all been changed to

Unicode.

For example, AbtOdbcVarCharField has now been changed to AbtOdbcUnicodeVarCharField.

The error I run into first, is when I try to use a String that I

am to obtain from a row in the database.

This String is now a Unicode String, and when I try to

open a directory, using 

CfsDirectoryDescriptor opendir: aString pattern: nil mode: FREG.

I get a primitive failed error in

CfStat>>#platformFunctionFindFirstFile: lpszSearchFile dta: lpffd

where that lpszSearchFile parameter is now the Unicode String.

Am I missing something obvious in the INI file, or some kind of configuration

setting?

I recognize that I can simply go back to the previous edition of

buildTypeDict (tried that...it works), but I don't like the idea of messing

with base code, especially if I am SUPPOSED to be doing something

different.

Any thoughts/help would be appreciated.

Urgency on this is moderately high.  I was planning on releasing a new

update of my software next week....but thought I would upgrade to

VAST 13 first....and I'd rather not reimplement all of the new changes

in my old VAST 12 image, if possible....

Thanks in advance for any feedback!

Regards,

Julian Ford

[Esteban A. Maringolo]

Hello Julian,

Can you tell me what version of the ODBC Driver are you using and what backend database engine you end connecting to? What's the encoding of the DB/TABLE/COLUMNS involved?

If you look at the "inverse" type dictionary (buildTypeStringDict) you'll find that these types are properly mapped, and in the past they weren't there, falling back to SQL_VARCHAR.

from AbtOdbcDatabaseManager class>>#buildTypeStringDict:

at: 'SQL_WLONGVARCHAR' put: -10;
at: 'SQL_WVARCHAR' put: -9;
at: 'SQL_WCHAR' put: -8;

The "W" prefixed types are meant to contain UTF-16 encoded strings (or chars), and if you're getting the right "string" (semantically) out of them, then they're working as expected. 

Of course, there might be something wrong with the existing mapping that we haven't caught yet, but I would appreciate more details to better understand anything that might be wrong and can be easily fixed for you and included in the next minor release.

Best regards,

Esteban Maringolo Senior Software Developer  emari...@instantiations.com  @emaringolo  /emaringolo  instantiations.com

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/dc3cdb7c-1fce-4b4a-a53e-9c7fe835666fn%40googlegroups.com.

[Esteban A. Maringolo]

Hi Julian,

Replying to myself, I'm going to make a wild guess here, assuming you're using SQL Server as the database server and ODBC driver.

We recently had a support case where the DATETIME/DATETIME2 type ids mapping was handled wrong, and that was because the customer was using the default ODBC SQL Driver shipped with Windows (v10.0.22621), but after upgrading to the latest version (v2018.183.02, "ODBC Driver 18 for SQL Server") the mapping started working as expected.

So to reproduce your issue I tried with MSSQL 18 (MSODBCSQL18.DLL), MSSQL 17 (MSODBCSQL17.DLL) and the default (MSSQL 10, SQLSRV32.DLL). The type id was wrong only with the default MSSQL 10 driver, meaning I was getting a UnicodeString instance where I should be getting regular, codepage converted, String. You should only get WVARCHAR/WCHAR if you're using a Unicode enabled connection (with *W functions) or if you have NVARCHAR column types.

So if my guess about you using MS SQL Server as the database was right, I'd recommend upgrading to the latest version of the driver, that will also solve other issues we found. 

If my guess was wrong, we'll keep discussing internally whether to rollback the change, or guard it somehow to preserve backward compatibility of the wrong mapping (or unified mapping).

Best regards,

Esteban Maringolo Senior Software Developer  emari...@instantiations.com  @emaringolo  /emaringolo  instantiations.com