Remote DB datasource datatype conversion issue

[llarge]

Hello all, I have found a weird data type conversion issue when using my remote database as a data source. I have a SQL view on a Microsoft SQL Server instance that I want to use as a data source for a form widget. I was able to create the data source just fine but I started getting into issues when I was debugging my button helper program. I was using GetFormChar for a field and it was returning a weird sequence of characters that was not what I was expecting. I eventually noticed that when I'm creating the data source, that column's type in NAB was Graphic.
https://www.screencast.com/t/k4o1cYGy9
Here is the view in my SQL server.
https://www.screencast.com/t/NZp7h92Sz
Here you can see that the TRATSCode column is set to varchar. It was char but I wanted to test another char type to see if it did the same thing. The msg1 msg2 and msg3 are set as char and they also show as Graphic in NAB.
I was able to get my button helper program working to pull the correct value by using GetFormGraphic which confirms that NAB is setting that column as graphic and not Char. The int and decimal data types come over to NAB just fine. They get converted to Numeric in NAB.
Not to make this post too long but I also noticed that GetFormChar on my numeric field returns the correct value. I'm putting that value into a Char var so no crashes but it is at least the value I expected.
https://www.screencast.com/t/Osvxnhic8eij
Hopefully, this all makes sense. I can make my button helper program work, but I figured that was a bug that you all might want to take a look at.
Thanks.

[robert.swanson]

This is actually not a bug. It's a nuance specific to remoteDBs.

In NAB there is special logic that limits the characters users can enter into a filter or form field based on the underlying field type. This is necessary because in a standard IBM i DB2 file, Char or Varchar fields cannot accommodate double byte characters, or any other characters outside of the underlying CCSID definition.

Most other databases (SQL Server, MySQL, etc) use standard unicode in their character fields, so there are no restrictions. But in a NAB app running in the IBM i world, we can only allow users to key "non-standard" character values into Graphic, J-type and O-type fields.

For this reason, in NAB all character fields coming from non-IBM i remoteDBs are treated as Graphic. Otherwise NAB would block perfectly acceptable special characters, in particular double-byte symbols for Japanese, for which we have a substantial user base.

[llarge]

Hello Robert, thanks for the information. That does make sense. I'll keep going since I found GetFormGraphic and that procedure lets me do what I need to with these values.
Have a great rest of the day.