在早期的Oracle是沒有中文的字符集（如Oracle6、Oracle7、Oracle7.1）,盡管如此數據庫在那時也有人運用了, 並用US7ASCII字符集存儲了中文，或是有的用戶在創建數據庫時，不考慮清楚，隨意選擇一個默認的字符集，如WE8ISO8859P1或US7ASCII，而這兩個字符集都沒有漢字編碼。
雖然有些時候選用這種字符集好象也能正常使用，但用這種字符集存儲漢字信息從原則上說就是錯誤的，它會給數據庫的使用與維護帶來一系列的麻煩。
正常情況下，要將漢字存入數據庫，數據庫字符集必須支持中文，而將數據庫字符集設置為US7ASCII等單字節字符集是不合適的。US7ASCII字符集只定義了128個符號，並不支持漢字。另外，如果在SQL*PLUS中能夠輸入中文，操作系統缺省應該是支持中文的，但如果在NLS_LANG中的字符集設置為US7ASCII，顯然也是不正確的，它沒有反映客戶端的實際情況。
但在實際應用中漢字顯示卻是正確的，這主要是因為Oracle檢查數據庫與客戶端的Oracle字符集設置是同樣的，那麼數據在客戶與數據庫之間的存取過程中將不發生任何轉換，但是這實際上導致了數據庫標識的字符集與實際存入的內容是不相符的。
而在SELECT的過程中，Oracle同樣檢查發現數據庫與客戶端的字符集設置是相同的，所以它也將存入的內容原封不動地傳送到客戶端，而客戶端操作系統識別出這是漢字編碼所以能夠正確顯示。
在這個例子中，數據庫與客戶端都沒有設置成中文Oracle字符集，但卻能正常顯示中文，從應用的角度看好象沒問題。然而這裡面卻存在著極大的隱患，比如在應用length或substr等字符串函數時，就可能得到意外的結果。
對於早期使用US7ASCII字符集數據庫的數據遷移到Oracle8i/9i中（使用zhs16gbk），由於原始數據已經按照US7ASCII格式存儲，對於這種情況，可以通過使用Oracle8i的導出工具，設置導出字符集為US7ASCII，導出後使用UltraEdit等工具打開dmp文件，修改第二、三字符，修改 0001 為0354,這樣就可以將US7ASCII字符集的數據正確導入到ZHS16GBK的數據庫中。
總結一下在 .Net 中讀寫Oracle數據庫常用兩種方式：OracleClIEnt和OleDb，其中OleDb的方式根據驅動程序的不同又有兩種。
1. OracleClIEnt方式，是微軟專門針對Oracle數據庫開發的，僅在 .Net Framework 1.1 版中受支持。據說速度快、性能好，是推薦使用的方式。但根據我的經驗，當Oracle數據庫服務器端采用英文字符集比如 US7ASCII 時，客戶端不管Oracle字符集如何設置，讀出的中文都是亂碼；若服務器端用中文字符集比如 ZHS16GBK ，則無亂碼問題。
引用類庫：System.Data.OracleClIEnt.dll。
命名空間：System.Data.OracleClIEnt。
常用類：OracleConnection、OracleCommand、OracleDataAdapter、OracleTransaction、OracleDataReader等。
典型連接字符串：“data source=oratest;user id=scott;passWord=tiger”（注意：可不指定 provider 驅動）。
2. OleDb方式，微軟和Oracle公司各自提供了OleDb的驅動程序，使用方法的差別很少。不管Oracle服務器端用何Oracle字符集，讀寫中文均無亂碼問題。
相同之處
命名空間：System.Data.OleDb。
常用類：OleDbConnection、OleDbCommand、OleDbDataAdapter、OleDbTransaction、OleDbDataReader等。
不同之處
引用類庫：微軟的只需要System.Data.dll；若用Oracle的驅動，雖然也只要引入System.Data.dll，但前提是首先安裝Oracle針對.Net的數據訪問組件。
連接字符串：與OracleClIEnt方式相比，要添加一個provider，微軟為
- “provider=MSDAORA.1;”，Oracle為“provider='OraOleDb.Oracle';
”set conn=server.createobject("adodb.connection")- dns="Provider=OraOLEDB.Oracle.1;Persist Security Info=True;
User ID=user1;PassWord=pass1;Data Source=oradb"
