ms sqlserver: NVARCHAR(99) --> NTEXT(null) / NVARCHAR(99) --> TEXT(99)

[Sanmargar]

I found two easy methods to check the table structure.

1.
SQLDSGenerator gen = new SQLDSGenerator(tableName, schema, dbName, serverType, timestampType, returnSQLTypes);
gen.generate();

2.
List<Map> fieldsFromTable = BuiltinRPC.getFieldsFromTable(tableName, schema, dbType, dbName);


Unfortunately, the first one changes the NTEXT data type to TEXT. The second one reads the data type correctly but loses the field length and returns nulls.


CREATE TABLE ntexttest (
ID int IDENTITY(1,1) NOT NULL,
NTEST nvarchar(99),
TEST varchar(99)
);


smartgwt.version=13.0-p20240707
mssqljdbc.version=12.6.3.jre11
select @@version :
Microsoft SQL Server 2022


Using the older version of the JDBC driver, it's the same.

mssqljdbc.version=9.2.1.jre8

[Isomorphic]

Hi Sanmargar, thanks for pointing this out.

With regards to the latter method (BuiltinRPC.getFieldsFromTable()), it could be improved to use ntext specifically for SQL Server, although this is a fairly obscure usage (and we are seeing a lot of customers migrating from SQLServer to Postgres!) . We'll take a look - we would probably have to add a backcompat flag.

In the meantime, the mechanism here is the same as autoDeriveSchema, and you could use that approach and redefine this one field to have type "ntext". You can even do this on the fly with a DataSource.fromXML(), with a short XML definition that uses autoDeriveSchema and overrides just the one field's type.

With regards to the former method (using SQLDSGenerator), your usage here isn't documented - indeed the documentation of this class does not enable it to be used at all. We will check into this, as it's probably a case of inadvertently exposed docs for something intended to remain an internal class. So, at least for now, we would not recommend continuing to try to use this class, as we will feel free to change the undocumented APIs you are using without notice, leading to possible breakage on upgrades.