A client is planning to move to Oracle 19 - first testing deliver errors on strings -
Type mismatch for field 'HEITI', expecting: String actual: WideString
As far as I can tell, this occurs when components have fields added, removing the field in question and adding back solves the problem.
This may be related to change of character set...
This particular field is defined as varchar2(50), in the older version a field of type string of size 50 was created, if I delete the field, I get a new one of type widestring and size 2000
I have tried option, forcewidestringfields, but no difference.
Any way I can solve this without manually delete and get all fields?

For Unicode UTF8 databases you will get TWideStringFields. If you previously used a single-byte character database, and if ForceWideStringFields was disabled, you will get TStringFields. To solve this you can:

• Change all fields to TWideStringFields. Now you datasets are Unciode compatible.
• Set Oracle.NoUnicodeSupport to True at run-time in your application before making a connection. Now the database character set will be converted to the client character set of the NLS_LANG variable, which you can force to a single-byte character set.
• Recreate the Oracle19 database with a single-byte character set.

Well,

Thank you for a quick reply, as always.

(1) I guess I should have explained that I *did* think of changing to TWideStringFields, but 430 queries in 69 forms are not something I will do in 2-3 hours, especially as there does not seem to be any logic in the change of size.
(2) I see no Oracle NoUnicodeSupport option in properties, how would I set that?
(3) Huge and multiple databases for a multi national company with number of distributed applications - I am not going to ask them to modify their policy and downgrade all other applications.

I guess I was also a bit too optimistic, as we did a similar upgrade for another client over a year ago - that client uses Devart's Oracle components, and worked without any modifications to code - so I told my client I expected this change to go smoothly...

Any other ideas? Or more information on (2)?

About option 2: this is a global variable in the Oracle unit. You can simply use the following statement during application initialization:

Again, thanks for a quick reply - I was assuming it was TOracleSession property, perhaps hidden.
But is only solves my problem partly.
My current applications seem to work and display characters correctly - although have not performed extensive testing.
However, if I add a component or a string field to a query, and fetch the fields in the designer, I get TWideString and the 'reverse' error.
Is it possible to have this as a property on TOraceSession, which would then also work for the designer in my database forms?

The "NoUnicodeSupport" run-time option allows your application to run the same on single-byte character databases and UTF8 databases. You would still need to develop your application on a single-byte character database though. If you develop on a UTF8 database, you will indeed get TWideStringFields at design-time.

Thank you for your reply, please reconsider having this option for design mode as well, through TOracleSession, it is not acceptable to design in one environment and run in another.
I assume I am not the only developer running into this kind of problem.
Should I be concerned that DOA will not be supported / developed in coming years?

I have added this to the list of enhancement requests. We will continue to support & developer DOA in the future.