Greenplum（PostgreSQL）的SAS/ACCESS＆客戶端編碼

正試圖找到一種方法來指示ODBC驅動程序 - Datadirect ODBC將win1251用於客戶端會話。Greenplum（PostgreSQL）的SAS/ACCESS＆客戶端編碼

有用戶指南中提到的方法：

使用PSQL的\編碼命令，它允許你動態修改客戶端編碼。
使用SET client_encoding TO：=> SET CLIENT_ENCODING TO'value';
使用PGCLIENTENCODING環境變量。
在postgresql.conf文件

但設置配置參數CLIENT_ENCODING據我所瞭解的選項1和3不適合的ODBC驅動程序，選擇2我也不能使用 - 因爲我使用SAS而且這個引擎不允許我執行手動編輯的SQL - 它使用了很多自動代碼生成。

我已經試過選項CLIENT_ENCODING在postgresql.conf文件，而且我已經厭倦了在PSQL管理會議，執行跟隨clommand：alter user sasuser SET client_encoding to WIN1251;但沒有任何變化 - 默認客戶端編碼仍然UTF8 ...

目前

中的DataDirect odbc.ini文件我有如下字符串：

IANAAppCodePage=2251

可能有人幫助我嗎？

來源

2011-11-21 Yury Kochubeev

實測值THT問題是在SAS/ACCESS爲greenplim - 當我們使用SQL傳遞然後將編碼集來win1251，但是當我們使用LIBNAME訪問同一數據源形成相同的用戶帳戶，並從相同的環境中SAS編碼切換到UTF8。出於某種原因，SAS/ACCESS的Greenplum的發送eplicit命令Greenplum的：'設置CLIENT_ENCODING到utf8'和泰德是問題的根源。不幸的是 - 我們沒有找到辦法如何解決這一問題... –

這絕對應該做的伎倆：

ALTER USER sasuser SET client_encoding TO WIN1251;

僅存的解釋可以是：

你實際上連接到數據庫使用不同的用戶。
在連接期間的某個點client_encoding被明確設置爲另一個值。
您連接到錯誤的數據庫集羣（同一IP？同一端口？）

爲了找到答案，設置log_statements = all，使服務器集羣重裝，開始與您的用戶不友好的工具會話，並檢查數據庫日誌，以及實際傳達給服務器的內容。不要忘記重置log_statements，否則您的日誌文件將會變大。

~~或者是所有的只是一個錯字在 Datadirect ODBC.ini：~~

~~IANAAppCodePage=2251~~

~~那應該是1251？~~

沒有。 IANAAppCodePage MIBenum 2251代表「WINDOWS_1251」。不是這個。

來源

2011-11-21 13:36:13

我在我的客戶發送命令日誌文件見'SET CLIENT_ENCODING TO「UTF8''的初始化階段...問題是 - 如何配置我的客戶端（通過ODBC SAS）不發出此命令... –

@YuryKochubeev：你檢查錯字的事情嗎？其實，這應該是正確的。 2251 - > WINDOWS_1251。 –

不，在ODBC ini中沒有錯別字。 - 2251是1251的代碼頁MIB值... –

Greenplum（PostgreSQL）的SAS/ACCESS＆客戶端編碼

回答

相關問題