なるほどここか。。
逐一悩まされるのですがこれも慣れ、ですかね。
C:\Users\(ログインユーザ名)\AppData\Roaming\Microsoft\Windows\SendTo
2012年9月23日日曜日
2012年9月8日土曜日
Oracle~Accessでの文字化け(チルダ、WAVEダッシュ)
OracleデータベースをリンクテーブルにてAccessから参照する仕組みです。
Oracle側の文字コードがUTF8のため、クライアントPC側もNLS_LANG=AL32UTF8、としていたのですが文字化け問題が発生。
波線・チルダ・WAVE DASH ⇒ 一つのカラムに含まれるだけで、行全体が♯DELETED
【解決策】
NLS_LANG = JAPANESE_JAPAN. JA16SJISTILDE
(クライアントPCの環境変数のみ設定)
とすることで、無事表示できました。
そもそもWindows環境ではUTF8は取り扱いが難しいため、割り切ってDBにはUTF8で格納(正しJIS第2水準までとして入力チェック)、Accessから見せる場合はOracle Clientによる文字コード変換結果、SJIS(TILDE)として見せる、という方式にしました。
Oracle側の文字コードがUTF8のため、クライアントPC側もNLS_LANG=AL32UTF8、としていたのですが文字化け問題が発生。
波線・チルダ・WAVE DASH ⇒ 一つのカラムに含まれるだけで、行全体が♯DELETED
【解決策】
NLS_LANG = JAPANESE_JAPAN.
(クライアントPCの環境変数のみ設定)
とすることで、無事表示できました。
そもそもWindows環境ではUTF8は取り扱いが難しいため、割り切ってDBにはUTF8で格納(正しJIS第2水準までとして入力チェック)、Accessから見せる場合はOracle Clientによる文字コード変換結果、SJIS(TILDE)として見せる、という方式にしました。
Microsoft Accessで循環参照を解消する方法
リンクテーブルに対して日本語で別名をつけて操作する仕組みを作ろうとしていたのですが、MAILというカラム物理名に対してMAILというカラム論理名称をつけようとしたところ、「循環参照」のエラーとなりました。。(「メール」でもよかったのですが、設計書から自動生成して一元管理したかったので)
【解決方法】
× SELECT MAIL AS MAIL FROM 住所録TBL ⇒ 循環参照でエラー
○ SELECT 住所録TBL.MAIL AS MAIL FROM 住所録TBL ⇒ OK!
【解決方法】
× SELECT MAIL AS MAIL FROM 住所録TBL ⇒ 循環参照でエラー
○ SELECT 住所録TBL.MAIL AS MAIL FROM 住所録TBL ⇒ OK!
Tera Term のログウィンドウを非表示にする。
設定ファイル(INIファイル)を直接編集します。
※デフォルトは C:\Program Files\teratarm\TERATERM.INI
LogHideDialog=on
2012年7月30日月曜日
Windows7のスタートアップフォルダの場所
自宅PCをWindows7にしてから早2年が経とうとしています。
が、昔ほど家でPCをいじる余裕とモチベーションもなく、
漫然と使っていたところ都度都度ハマります。。
例えばスタートアップへの追加削除。
XPだと「スタート」メニューからたどり、「スタートアップ」フォルダで
右クリック、「開く」でエクスプローラが立ち上がりそこでショートカットファイルを直接編集する、という至極当然の流れだったのが通用しない。
同じ事をWin7でやると、「system32」フォルダが開いてしまいます。。。
どうすればよいのか。。
で、調べた結果を備忘録として記録。
Windows7のスタートアップフォルダの場所は以下となります。
マイコンピュータ
→C:
→ユーザー
→(ユーザー名)
→AppData
→Roaming
→Microsoft
→Windows
→スタートメニュー
→プログラム
→スタートアップ
※ちなみに「AppData」では隠しフォルダなので要注意。
2012年7月29日日曜日
フォントを綺麗にするだけで作業ストレス改善→生産性2.3倍
【MacType vs gdi++】
・MacType → Google Chromeでも有効
・MacType → Office2007でのVBA Editorでも有効
私個人の実感値からの算出倍率なので、誰にでも当てはまるわけではありませんが、もし統計を取れば確実にストレス改善→集中力UP→作業スピード・品質UP→生産性向上、につながるはず。と考えます。これにプラスして、画面領域の拡大(=大画面ディスプレイ)も加われば最強かと。
何に比べてか、というと、CPUパワーやメモリ容量のベクトルでの生産性向上施策に対して蔑ろにされがちなこれらの要素が実は作業への負荷云々に対してのゴホンゴホン・・・
ちょっと前置きが鬱陶しすぎると自分でも気がついたので本題。
gdi++を長いこと使用していたのですが、この度評判のMacTypeに切り替えました。
機能的には双方大きな違いは感じなかったため不便はしていなかったのですが、1点だけ問題が。
もともとOfficeのVBA Editorとgdi++は相性が悪いのか、文字化けというか表示崩れのため、VBAの編集がまま
ならず、その作業の際は必ずgdi++サービスを停止するようにしていました。
ところが最近Office2007にバージョンアップしたところ、gdi++のサービスを停止してもこれが解消されず途方にくれることに。
そこで試しにMacTypeに切り替えてみたのですが、これでうまいこと解消されました。
"サービスモード","独立モード"両方共問題なく動作しています。
ちょっと中国語のインターフェースが違和感。。を正直感じていたのですが(これまで中国語ソフトは
使ったことがなかったので)なれれば気になりません。
まとめると、
【MacType vs gdi++】
・MacType → Google Chromeでも有効
・MacType → Office2007でのVBA Editorでも有効
上記2点だけですがそれでも十分なほどこちらを選ぶ根拠になりました。
・MacType → Google Chromeでも有効
・MacType → Office2007でのVBA Editorでも有効
私個人の実感値からの算出倍率なので、誰にでも当てはまるわけではありませんが、もし統計を取れば確実にストレス改善→集中力UP→作業スピード・品質UP→生産性向上、につながるはず。と考えます。これにプラスして、画面領域の拡大(=大画面ディスプレイ)も加われば最強かと。
何に比べてか、というと、CPUパワーやメモリ容量のベクトルでの生産性向上施策に対して蔑ろにされがちなこれらの要素が実は作業への負荷云々に対してのゴホンゴホン・・・
ちょっと前置きが鬱陶しすぎると自分でも気がついたので本題。
gdi++を長いこと使用していたのですが、この度評判のMacTypeに切り替えました。
機能的には双方大きな違いは感じなかったため不便はしていなかったのですが、1点だけ問題が。
もともとOfficeのVBA Editorとgdi++は相性が悪いのか、文字化けというか表示崩れのため、VBAの編集がまま
ならず、その作業の際は必ずgdi++サービスを停止するようにしていました。
ところが最近Office2007にバージョンアップしたところ、gdi++のサービスを停止してもこれが解消されず途方にくれることに。
そこで試しにMacTypeに切り替えてみたのですが、これでうまいこと解消されました。
"サービスモード","独立モード"両方共問題なく動作しています。
ちょっと中国語のインターフェースが違和感。。を正直感じていたのですが(これまで中国語ソフトは
使ったことがなかったので)なれれば気になりません。
まとめると、
【MacType vs gdi++】
・MacType → Google Chromeでも有効
・MacType → Office2007でのVBA Editorでも有効
上記2点だけですがそれでも十分なほどこちらを選ぶ根拠になりました。
2012年7月15日日曜日
新しいiPad タッチペン、スタイラス選び。。
店頭で探すも色々ありすぎて迷う。
そしてなかなか実物を触れる用になっていないので、買ってみるしか無いのです。
勢いでいくつか。これから使い比べてみます。
そしてなかなか実物を触れる用になっていないので、買ってみるしか無いのです。
勢いでいくつか。これから使い比べてみます。
登録:
投稿 (Atom)