Problem solved as in the previous case. Simply manually editing the TPLACTUAL on DB.... Thanks Regards Claudio

Hello Peter, thanks for the suggestions. Even though there seems to be a change in Uniface between U96 and U97. Since this problem didn't occur in U96. And Uniface version is the only change I have made (I switched from U96 to U97). Everything else is the same - the same Oracle client, the same Oracle server, the same Data... My table is really very small. Only 4 columns: CHAR(36 CHAR), VARCHAR2(100 CHAR), INTERVAL DAY(2) TO SECOND(6), INTERVAL DAY(2) TO SECOND(6). There are only 2 rows in the table. I changed the sql from "select * from..." to "select first_column from...". The first column is always full of data, it's kind of uuid. So NLS_LENGTH_SEMANTICS shouldn't be a problem here. It seems to me, that those "interval" fields are problem form U97. Kind regards, Zdeněk Socha

01406 errors are usually caused by an error in the NLS setup for Oracle and Uniface or a mismatch between actual definition for tables in the Oracle database and the definitions Uniface expects based upon the used Oracle connector options. For the NLS setup there is an explanation on the points to watch for: Explanation via bug 28891 - Uniface , Oracle and Oracle setting NLS_LENGTH_SEMANTICS http://unifaceinfo.com/fixes/issuelist/28891.php   For the Uniface SQL workbench there are limitations like no LOB fields in the workbench. Unicode in the workbench is only possible when using $def_charset=UTF8 and Unicode fonts.   You can also check the Oracle support site for known Oracle issues. If this does not help I advice to log a case with Uniface support.   Peter Beugel

Hello, seems to me like a bug in Uniface 9.7... I have just migrated our very simple application from U96 to 9.7.02.02 (G202 0713_1) and I'm facing the same problem... One of the first commands is a very simple sql/data "select * from my_table" ... in U96 this is ok, but in Uniface 9.7.02 it fails with this in a log file: I/O function: Q, mode: 7, on driver: ORA ORA-01406: znaky načtené hodnoty sloupce byly zkráceny ORACLE Driver Error [-28]: sql driver function (SQL Workbench or sql Proc instruction) failed. ORA-01406: znaky načtené hodnoty sloupce byly zkráceny ORACLE Driver Error [-28]: sql driver function (SQL Workbench or sql Proc instruction) failed. Any help? Zdeněk Socha EDIT: After some googling.... I have resolved the issue by changing the sql from "select * from my_table" into "select my_column from my_table". It seems like Uniface declares too small buffer and/or wrong datatype for some columns (in my case there are some columns of datatype "INTERVAL DAY(2) TO SECOND(6)").

gianni said

Yes, we are...it's a forum to discuss potential issues... Sometimes they are confirmed, sometimes not...when confirmed a bug must be opened. Gianni  

Hope it will be confirmed...or not! Regards Claudio I'm still waiting for your mail with samples 

Claudio said

gianni said

Claudio said ... what I'm hoping is to have official support, for this kind of problems...  

Claudio, this forum is put in place to enable communications and exchange of informations. Procedures to have official support are listed on this site into the "support" menu avilable on main page. You should open a case, providing proper description and a way to reproduce the issue. Gianni  

Thanks for the hint. Just a clarification, we are under: Uniface Development -> Uniface 9 -> Bugs, Issues and Errors Regards Claudio  

Yes, we are...it's a forum to discuss potential issues... Sometimes they are confirmed, sometimes not...when confirmed a bug must be opened. Gianni

gianni said

Claudio said ... what I'm hoping is to have official support, for this kind of problems...  

Claudio, this forum is put in place to enable communications and exchange of informations. Procedures to have official support are listed on this site into the "support" menu avilable on main page. You should open a case, providing proper description and a way to reproduce the issue. Gianni  

Thanks for the hint. Just a clarification, we are under: Uniface Development -> Uniface 9 -> Bugs, Issues and Errors Regards Claudio

Claudio said ... what I'm hoping is to have official support, for this kind of problems...  

Claudio, this forum is put in place to enable communications and exchange of informations. Procedures to have official support are listed on this site into the "support" menu avilable on main page. You should open a case, providing proper description and a way to reproduce the issue. Gianni

gianni said Claudio, What have you done is implying Oracle driver uses CLOB/BLOB in the same identical way as it was using LONG/LONG RAW before but unfortunately I cannot give any support on this. The official procedure to be followed after gaining access somehow to a corrupted repo is: - export object(s): in your case components for sure but the whole repo is not a bad idea. - recreate the repo using available scripts - reimport object(s) The experience you've passed through is very unusual; I feel something is wrong there. Could you please share these infos to enable a more detailed analysis: - Uniface full version (patch level installed) - Uniface Oracle driver version used - Uniface Oracle driver configuration - Oracle client full version (patch level installed) - Oracle server full version (patch level installed) Gianni  

Gianni, I really appreciate your help, but what I'm hoping is to have official support, for this kind of problems. - Uniface Full Version (in the subject): "9.7.03.02 (G302 1012_1)" - Uniface Oracle driver version used: "ORA = U6.3" (hoping this is what you ask for, if I understand) - Uniface Oracle driver version config: "fv, dhfr, disable rowid" (hoping this is what you ask for, if I understand) - Oracle client: "Oracle Instant Client 10.2.0.5.0 - 32-bit" (I need to verify) - Oracle Server: "Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production" Uniface and Oracle RDBMS are on the same machine, but I'm pretty sure this is not an issue. You are right! It's never a good idea not follow the official procedures, but I suspect that Uniface has problems when saving CLOB/LONG after a copy/paste. In fact, saving data with an Oracle editor, the problem in the data was fixed. Next time, though I sincerely hope that never happen again, I will export the repository to make it available to the official support. Really Thanks Regards Claudio

Claudio, What have you done is implying Oracle driver uses CLOB/BLOB in the same identical way as it was using LONG/LONG RAW before but unfortunately I cannot give any support on this. The official procedure to be followed after gaining access somehow to a corrupted repo is: - export object(s): in your case components for sure but the whole repo is not a bad idea. - recreate the repo using available scripts - reimport object(s) The experience you've passed through is very unusual; I feel something is wrong there. Could you please share these infos to enable a more detailed analysis: - Uniface full version (patch level installed) - Uniface Oracle driver version used - Uniface Oracle driver configuration - Oracle client full version (patch level installed) - Oracle server full version (patch level installed) Gianni

Hi Claudio, Oracle error ORA-01406 means: when data is fetched from RDBMS to memory there is not enough space to hold ALL available data and column value is truncated to max value. Hint: what is different for this DSP: is its size huge? If YES: what was included into it? If NOT: could you please verify into log files (with high details) which column is causing error? Gianni

Hi, I did it my way and, simply by modifying the "TPLACTUAL" DSP's field which generated the problem. After the COMMIT all things work again (I deleted a space in a random comment line, so nothing of special). After, I've migrated the repo with CLOB/BLOB instead of LONG old. Everything worked fine yesterday but, a few minutes ago, when saving a DSP ...

In the image the actual situation: - the blank line is the DSP I was working on - it's not the same DSP as before - I've simply done a copy/paste from another DSP - It's a bit frustrating... Thanks all Regards Claudio

Claudio, I know you should not have (yet) so many DSP in your repo... :-) Let's have a look to result for the following SQL statement on path $IDF:       select ulabel, utimestamp, ucompstamp from uform where utransact = 7; You could try to "clean up" your repo, after doing a backup of your oracle schema where Urepo is hosted. At the small window starting UDE type: /cln ComponentName or /cln * and wait for completition... More info on Uniface Library. IMHO you should anyhow upgrade your repo to use CLOB/BLOB instead of LONG/LONG RAW. Gianni

Hi Gianni, and thanks for your answer!

gianni said AFAIK there is only ONE point where UDE is searching on UFORM without any componentname explicitely defined and it is in the dialog dedicated to choose which component to open...This component MUST work! Are you REALLY sure you repo is currently NOT containing any garbage? You can use SQL workbench (or another Oracle utility) to directly access UFORM (and OUFORM) table(s) with following statements: - select ulabel, utimestamp, ucompstamp from uform; - select ulabel, segm from ouform; In both cases ulabel is (part of) the PrimaryKey and it MUST be filled only with uppercase alpha or numeric or underscore. If this is not the case you have probably forced a commit somehow when it was not really appropriate.

In fact, that's the point, I can't open ANY DSP. I'm working only with the Uniface IDF, so I'm pretty sure to not have any kind of "garbage". I do not think what you mean when you say "you have probably forced a commit somehow when it was not really appropriate".

Data types: because of the history Uniface is currently supporting on Oracle different mapping modes; reason because your repo is using LONG datatype is VERY PROBABLY because you are using one of the the older mapping mode; see Uniface Library Oracle connector options to recognize these options: - u2 default mapping - u2 enhanced_mapping - u2 enhanced_mapping_2 - u36_compatibility - u4_compatibility Current Oracle driver with current configuration does NOT use anymore LONG/LONG RAW as you can see in this snippet from UDE SQL script provided:         "TPLACTUAL"                      CLOB, I suggest to stay (if possible) with the most current Oracle configuration. If you'll decide to change your Oracle mapping your repo must be exported with old configuration and reimported after re-creating the (correct) structure. SQL Scripts to recreate the repo are available in \\uniface\\sql\\ora*.sql.

Over the years the repo was never recreated from IDF, so I think we have a problem!  Thanks all Regards Claudio

AFAIK there is only ONE point where UDE is searching on UFORM without any componentname explicitely defined and it is in the dialog dedicated to choose which component to open...This component MUST work! Are you REALLY sure you repo is currently NOT containing any garbage? You can use SQL workbench (or another Oracle utility) to directly access UFORM (and OUFORM) table(s) with following statements: - select ulabel, utimestamp, ucompstamp from uform; - select ulabel, segm from ouform; In both cases ulabel is (part of) the PrimaryKey and it MUST be filled only with uppercase alpha or numeric or underscore. If this is not the case you have probably forced a commit somehow when it was not really appropriate. Data types: because of the history Uniface is currently supporting on Oracle different mapping modes; reason because your repo is using LONG datatype is VERY PROBABLY because you are using one of the the older mapping mode; see Uniface Library Oracle connector options to recognize these options: - u2 default mapping - u2 enhanced_mapping - u2 enhanced_mapping_2 - u36_compatibility - u4_compatibility Current Oracle driver with current configuration does NOT use anymore LONG/LONG RAW as you can see in this snippet from UDE SQL script provided:         "TPLACTUAL"                      CLOB, I suggest to stay (if possible) with the most current Oracle configuration. If you'll decide to change your Oracle mapping your repo must be exported with old configuration and reimported after re-creating the (correct) structure. SQL Scripts to recreate the repo are available in \\uniface\\sql\\ora*.sql. Gianni

Also here:

I could send the entire log file. Thanks Regards Claudio ---EDIT--- Checking UFORM table in the repo, I've found that the type of TPLACTUAL column is LONG. According with Oracle: Oracle Data Types Regards Claudio

Claudio said

Arjen van Vliet said This could also be qualified as an Oracle bug, according to this article  

Thanks, It's running on Oracle XE 11g (11.2.0.2.0) 64bit. I've not access to the MOS, but I'm not sure about it... Regards Claudio  

Sorry, I was not clear. I'm not sure that this is the BUG you mentioned. Thanks Regards Claudio

gianni said Hi Claudio, Oracle error ORA-01406 means: when data is fetched from RDBMS to memory there is not enough space to hold ALL available data and column value is truncated to max value. Hint: what is different for this DSP: is its size huge? If YES: what was included into it? If NOT: could you please verify into log files (with high details) which column is causing error? Gianni  

Thanks, the DSP are very tiny and small. Here the log:

Thanks all Regards Claudio

Arjen van Vliet said This could also be qualified as an Oracle bug, according to this article  

Thanks, It's running on Oracle XE 11g (11.2.0.2.0) 64bit. I've not access to the MOS, but I'm not sure about it... Regards Claudio

This could also be qualified as an Oracle bug, according to this article