回答編集履歴

10

推敲

2020/11/06 01:20

投稿

sazi
sazi

スコア25329

test CHANGED
@@ -76,4 +76,4 @@
76
76
 
77
77
  ※[ASCIISTR](https://www.shift-the-oracle.com/sql/functions/ascii-chr-nchr.html)も追加
78
78
 
79
- `timestamp`型にすれば解決するょうけど
79
+ `timestamp`型にすれば回避はできそうですが、根本的な解決ではありませんし

9

推敲

2020/11/06 01:19

投稿

sazi
sazi

スコア25329

test CHANGED
@@ -72,7 +72,7 @@
72
72
 
73
73
  ```
74
74
 
75
- 手元の環境では変わりませんが、上記を実行すれば確認はできると思います。
75
+ 手元の環境では20バイトにはなりませんが、上記を実行すれば確認はできると思います。
76
76
 
77
77
  ※[ASCIISTR](https://www.shift-the-oracle.com/sql/functions/ascii-chr-nchr.html)も追加
78
78
 

8

追記

2020/11/06 01:16

投稿

sazi
sazi

スコア25329

test CHANGED
@@ -56,6 +56,12 @@
56
56
 
57
57
  , lengthb(to_single_byte(testtime))
58
58
 
59
+ , ASCIISTR (testtime)
60
+
61
+ , length(ASCIISTR (testtime))
62
+
63
+ , lengthb(ASCIISTR (testtime))
64
+
59
65
  from (
60
66
 
61
67
  select TO_CHAR(SYSTIMESTAMP(3),'YYYYMMDDHH24MISSFF3') testtime
@@ -68,4 +74,6 @@
68
74
 
69
75
  手元の環境では変わりませんが、上記を実行すれば確認はできると思います。
70
76
 
77
+ ※[ASCIISTR](https://www.shift-the-oracle.com/sql/functions/ascii-chr-nchr.html)も追加
78
+
71
79
  `timestamp`型にすれば解決するんでしょうけど。

7

追記

2020/11/06 01:14

投稿

sazi
sazi

スコア25329

test CHANGED
@@ -42,4 +42,30 @@
42
42
 
43
43
  解決するか分かりませんが、[to_single_byte](https://www.shift-the-oracle.com/sql/functions/to_multi_byte.html)を挟んでみてはどうでしょうか。
44
44
 
45
+ ```SQL
46
+
47
+ SELECT testtime
48
+
49
+ , length(testtime)
50
+
51
+ , lengthb(testtime)
52
+
53
+ , to_single_byte(testtime)
54
+
55
+ , length(to_single_byte(testtime))
56
+
57
+ , lengthb(to_single_byte(testtime))
58
+
59
+ from (
60
+
61
+ select TO_CHAR(SYSTIMESTAMP(3),'YYYYMMDDHH24MISSFF3') testtime
62
+
63
+ FROM DUAL
64
+
65
+ ) test
66
+
67
+ ```
68
+
69
+ 手元の環境では変わりませんが、上記を実行すれば確認はできると思います。
70
+
45
71
  `timestamp`型にすれば解決するんでしょうけど。

6

追記

2020/11/06 01:03

投稿

sazi
sazi

スコア25329

test CHANGED
@@ -41,3 +41,5 @@
41
41
 
42
42
 
43
43
  解決するか分かりませんが、[to_single_byte](https://www.shift-the-oracle.com/sql/functions/to_multi_byte.html)を挟んでみてはどうでしょうか。
44
+
45
+ `timestamp`型にすれば解決するんでしょうけど。

5

訂正

2020/11/06 00:58

投稿

sazi
sazi

スコア25329

test CHANGED
@@ -1,4 +1,6 @@
1
1
  「"テーブルA"."カラムA"の定義が、値より小さい」と言われているんだから、テーブル定義を直すしかありません。
2
+
3
+
2
4
 
3
5
  文字数で意識した定義にしているなら、そのように定義する必要があります。
4
6
 
@@ -25,3 +27,17 @@
25
27
 
26
28
 
27
29
  態々、文字型で定義しなくても、`TIMESTAMP`型で取る方が容量的には少なく済むし、利便性があると思いますけど。
30
+
31
+
32
+
33
+ 訂正
34
+
35
+ --
36
+
37
+ 列"テーブルA"."カラムA"の値が大きすぎます(実際:20、最大: 17)
38
+
39
+ 実際で20バイトという事は内容的にマルチバイト文字で扱われている所がありそうなので、別な問題ですね。
40
+
41
+
42
+
43
+ 解決するか分かりませんが、[to_single_byte](https://www.shift-the-oracle.com/sql/functions/to_multi_byte.html)を挟んでみてはどうでしょうか。

4

追記

2020/11/06 00:56

投稿

sazi
sazi

スコア25329

test CHANGED
@@ -20,4 +20,8 @@
20
20
 
21
21
  ```
22
22
 
23
+ 多分、現状では`char(17)`で定義しているんでしょうけど、`char()`指定の桁はあくまでバイト数なので、格納できる文字数は、文字コードの長さでまちまちです。
24
+
25
+
26
+
23
27
  態々、文字型で定義しなくても、`TIMESTAMP`型で取る方が容量的には少なく済むし、利便性があると思いますけど。

3

推敲

2020/11/06 00:37

投稿

sazi
sazi

スコア25329

test CHANGED
@@ -4,7 +4,11 @@
4
4
 
5
5
  `varchr2(17 char)`のように桁が文字の数を表しているという、指定(`char`)が必要です
6
6
 
7
+
8
+
9
+ 以下のSQLで作成された項目の定義を確認しました。
10
+
7
- 以下のSQLで作成された項目の定義を確認しました。少なくとも`Varchar2(17)`であれば大丈夫そうですが。
11
+ 少なくとも`Varchar2(17)`であれば大丈夫そうですが。
8
12
 
9
13
  ```SQL
10
14
 

2

追記

2020/11/06 00:29

投稿

sazi
sazi

スコア25329

test CHANGED
@@ -4,6 +4,16 @@
4
4
 
5
5
  `varchr2(17 char)`のように桁が文字の数を表しているという、指定(`char`)が必要です
6
6
 
7
+ 以下のSQLで作成された項目の定義を確認しました。少なくとも`Varchar2(17)`であれば大丈夫そうですが。
7
8
 
9
+ ```SQL
10
+
11
+ create table test as
12
+
13
+ select to_char(systimestamp(3),'YYYYMMDDHH24MISSFF3') dummy
14
+
15
+ from dual
16
+
17
+ ```
8
18
 
9
19
  態々、文字型で定義しなくても、`TIMESTAMP`型で取る方が容量的には少なく済むし、利便性があると思いますけど。

1

推敲

2020/11/06 00:28

投稿

sazi
sazi

スコア25329

test CHANGED
@@ -1,4 +1,8 @@
1
1
  「"テーブルA"."カラムA"の定義が、値より小さい」と言われているんだから、テーブル定義を直すしかありません。
2
+
3
+ 文字数で意識した定義にしているなら、そのように定義する必要があります。
4
+
5
+ `varchr2(17 char)`のように桁が文字の数を表しているという、指定(`char`)が必要です
2
6
 
3
7
 
4
8