數據-欄位中的換行符問題：delprioritychar，del，IXF相關

今日被分派另一個兄弟系統做小弟，剛剛接手就來一封郵件。

郵件詢問某表的建表結構，說是我們給的文件數據導入不能。

於是，把建表sql發給了他，額，DB2的建表和以前常擼的Oracle畢竟不太一樣。誠惶誠恐哦。

完了，這老師又來一封郵件，說是還是導入不能

Schema Column count (23) conflicts with columns received (6) in record 22.  麻烦确认一下表结构，如果表结构没有变动，麻烦检查文件是否有换行符

哎呀，記得以前也曾碰到過，應為是以del格式作為數據交換的文件載體，而出現因為DB中自帶換行符而導致導出的文件一條數據未完就換行，然後對方系統加載不能的情況。

那會好似使用trim把這個問題解決了。

但是現在這個換行符並不是因為用戶大意輸入導致，而是文本本身就自帶的，所以不能用trim去掉。

於是考慮修改數據文件載體的格式

del是文本格式，是可見的，但是是按行存儲，所以會有換行符的問題

ixf是集成交換文件，不可見，可以跨平台使用，聽說這個很合適于我這樣的情況。

嗎~一不做二不休

export to /home/appxxx/TRL/datamasking/pagecodetest/abc.ixf  of ixf messages msg.out  select * from xxxs.PRODUCT_SETTING;

看這個導出很簡單明了嘛。沒有什麼分隔符和編碼的設置，編碼加上會報錯，不知分隔符加上會不會報錯

import from '/home/appxxx/TRL/datamasking/pagecodetest/abc,ixf' of ixf  insert_update into xxxs.PRODUCT_SETTING_TEST;

這個導入也很簡單明了，也麼有分隔符和編碼的設置問題

 

好了~成功。感謝。。。。。可以給老師回復了。

 

但是還有一種方法

delprioritychar

就是，比如我導出的數據呢，設置了chardel，有引號包括著的，那麼一對引號內的換行符呢，就可以被認為是在一條數據內的，不會引起誤讀。

恩，就是設置優先級~引號優先于換行。