| |
| 1 |
2632049 |
| 2 |
|
| 3 |
|
| 4 |
Bug No: 2632049 |
| 5 |
Filed 18-OCT-2002 Updated 29-JAN-2003 |
| 6 |
Product Oracle Forms Product Version 9.0.2.7.0 |
| 7 |
Platform Microsoft Windows 2000 Platform Version No Data |
| 8 |
Database Version 9.0.2.0.0 Affects Platforms Generic |
| 9 |
Severity Severe Loss of Service Status Closed, Not a Bug |
| 10 |
Base Bug N/A Fixed in Product Version No Data |
| 11 |
|
| 12 |
Problem statement: |
| 13 |
|
| 14 |
MAX. LENGTH OF A FIELD IS NOT RESTRICTED WHEN ENTERING MULTI BYTE DATA |
| 15 |
|
| 16 |
|
| 17 |
|
| 18 |
*** 10/18/02 01:33 am *** |
| 19 |
|
| 20 |
. |
| 21 |
|
| 22 |
. |
| 23 |
|
| 24 |
Detailed Problem Description |
| 25 |
|
| 26 |
============================= |
| 27 |
|
| 28 |
Max. Length of a field is not restricted when entering Multi byte data after |
| 29 |
|
| 30 |
setting the "Data Length Semantics" property of the multi byte field to CHAR. |
| 31 |
|
| 32 |
This behaviour is exibited only when the user copies and paste's the data. |
| 33 |
|
| 34 |
But when the data into the field is entered manually the size is restricted. |
| 35 |
|
| 36 |
. |
| 37 |
|
| 38 |
As more data is getting entered, when saved through forms this error is raised |
| 39 |
|
| 40 |
: |
| 41 |
|
| 42 |
ORA-01401: inserted value too large for column |
| 43 |
|
| 44 |
. |
| 45 |
|
| 46 |
Diagnostic Analysis |
| 47 |
|
| 48 |
==================== |
| 49 |
|
| 50 |
This is happening only for Multi byte data that is copied and pasted. |
| 51 |
|
| 52 |
. |
| 53 |
|
| 54 |
. |
| 55 |
|
| 56 |
Generic/Port-specific findings |
| 57 |
|
| 58 |
============================== |
| 59 |
|
| 60 |
I have tested with Form 9.0.2.7.0, and Jinitiator 1.3.1.9 |
| 61 |
|
| 62 |
. |
| 63 |
|
| 64 |
Environment |
| 65 |
|
| 66 |
============ |
| 67 |
|
| 68 |
Platform ProductVersion Reproduced |
| 69 |
|
| 70 |
---------- ---------------- -------------- |
| 71 |
|
| 72 |
Win 2000 9.0.2.7.0 Y |
| 73 |
|
| 74 |
RedHatLinux 9.0.2.7.0 Y |
| 75 |
|
| 76 |
. |
| 77 |
|
| 78 |
Testcase step-by-step instructions |
| 79 |
|
| 80 |
==================================== |
| 81 |
|
| 82 |
1] Create a field that will store chinese characters with Varchar2(12) [ |
| 83 |
|
| 84 |
Structure given below] |
| 85 |
|
| 86 |
to Char. |
| 87 |
|
| 88 |
3] Type in some chinese characters. This field will accept only the stipulated |
| 89 |
|
| 90 |
number of |
| 91 |
|
| 92 |
characters ( something like 4 chinese characters) |
| 93 |
|
| 94 |
4] Now save this. This gets commited to the database with out any errors. |
| 95 |
|
| 96 |
5] Insert a new record |
| 97 |
|
| 98 |
6] Now copy and paste some chinese characters multiple times into this newely |
| 99 |
|
| 100 |
created field. |
| 101 |
|
| 102 |
7] Now when this newely pasted data is saved forms gives : |
| 103 |
|
| 104 |
ORA-01401: inserted value too large for column |
| 105 |
|
| 106 |
. |
| 107 |
|
| 108 |
. |
| 109 |
|
| 110 |
Testcase location |
| 111 |
|
| 112 |
=================== |
| 113 |
|
| 114 |
Create a table with the following structure in a UTF8 database. |
| 115 |
|
| 116 |
Create table len_test (COL1 VARCHAR2(12)). Then run the form provided below. |
| 117 |
|
| 118 |
. |
| 119 |
|
| 120 |
Files uploaded : Screen shot,Forms 9i form. |
| 121 |
|
| 122 |
files located at ess30 - /bug/bug2632049 |
| 123 |
|
| 124 |
. |
| 125 |
|
| 126 |
. |
| 127 |
|
| 128 |
. |
| 129 |
|
| 130 |
. |
| 131 |
|
| 132 |
Available Workarounds |
| 133 |
|
| 134 |
====================== |
| 135 |
|
| 136 |
1] Set Data Length Scemantics to Byte |
| 137 |
|
| 138 |
2] Enter data manually and do not copy and paste data in to the field |
| 139 |
|
| 140 |
. |
| 141 |
|
| 142 |
Related bugs |
| 143 |
|
| 144 |
============= |
| 145 |
|
| 146 |
None |
| 147 |
|
| 148 |
. |
| 149 |
|
| 150 |
*** 10/22/02 06:40 am *** (CHG: Asg->NEW OWNER) |
| 151 |
|
| 152 |
*** 10/28/02 12:16 am *** |
| 153 |
|
| 154 |
*** 10/28/02 02:58 am *** |
| 155 |
|
| 156 |
The behavior described here is correct: |
| 157 |
|
| 158 |
- in the database byte length is defined (*) |
| 159 |
|
| 160 |
- in the form char length is defined |
| 161 |
|
| 162 |
So you are allowed to enter 12 characters into the forms. |
| 163 |
|
| 164 |
But all these Chinese characters you have entered are at least 2 bytes long. |
| 165 |
|
| 166 |
So you cannot insert these into the DB. |
| 167 |
|
| 168 |
You have to define character length in the DB, if you want to use character |
| 169 |
|
| 170 |
length in the form. |
| 171 |
|
| 172 |
*** 10/28/02 03:19 am *** (CHG: Sta->32) |
| 173 |
|
| 174 |
*** 10/28/02 03:19 am *** |
| 175 |
|
| 176 |
(*) You can check with: |
| 177 |
|
| 178 |
SELECT CHAR_USED FROM USER_TAB_COLUMNS WHERE TABLE_NAME='LEN_TEST'; |
| 179 |
|
| 180 |
In this case here 'B' for Byte is returned. |
| 181 |
|
| 182 |
See Oracle 9i SQL Reference Manual, page 10-56/10-57. |
| 183 |
|
| 184 |
Create the table with this statement to use char length: |
| 185 |
|
| 186 |
CREATE TABLE LEN_TEST |
| 187 |
|
| 188 |
(COL1 VRACHAR2(12 CHAR)); |
| 189 |
|
| 190 |
Now the above query returns 'C' for Character. |
| 191 |
|
| 192 |
*** 10/28/02 03:24 am *** |
| 193 |
|
| 194 |
Yes, as explained by me in the bug earlier form sdoes restrict the length of |
| 195 |
|
| 196 |
chinese characters |
| 197 |
|
| 198 |
correctly when entering via the keyboard. But, when copying and pasting |
| 199 |
|
| 200 |
characters this character |
| 201 |
|
| 202 |
restriction seems to be ignored by forms. - Thanks |
| 203 |
|
| 204 |
*** 10/28/02 03:25 am *** (CHG: Sta->16) |
| 205 |
|
| 206 |
*** 10/28/02 03:56 am *** (CHG: Sta->32) |
| 207 |
|
| 208 |
*** 10/28/02 03:56 am *** |
| 209 |
|
| 210 |
The behavior you are describing is correct for Forms 6i where we had no |
| 211 |
|
| 212 |
Character Semantics Support. |
| 213 |
|
| 214 |
Before Forms 9i we only had Byte Length. |
| 215 |
|
| 216 |
But now we can decide if we want to use Byte Length - the default - or |
| 217 |
|
| 218 |
Character Length. |
| 219 |
|
| 220 |
You should use the same length type in the DB and in Forms to avoid errors. |
| 221 |
|
| 222 |
See Note 202748.1 for details. |
| 223 |
|
| 224 |
*** 11/15/02 07:23 am *** |
| 225 |
|
| 226 |
*** 01/29/03 08:59 am *** (CHG: Sta->92) |
| 227 |
|
| 228 |
. |
| |