雪国SEのひとりごと

愚痴ったり、メモったり、その他色々。人生は永い。焦る事は無い。人生前向きに考えると、きっといいことがあるよ。
【重要】当ブログの記事にて生じたいかなる損害について保証いたしません。

仕事

出張

今日は青森県内のとある自治体さんへ出張しました。

途中、ラーメン屋にて早めの昼食としました。
(前日に寄るようにお願いしておいたのだ)

そして食べたのはこれ。
チャーシューメン+ライスセットだったかな
ライスセットが半ライスと餃子3つが付きまして。
(餃子1つ食べてあわてて写真撮りました)

で、食後には割引券を使用です。
割引券

レジにて再度割引券をもらい、それの有効期限が平成22年2月末まで。
はたしてそれまでに来る機会があるかといえばあるけど、タイミング良い時間に入店できるかが不明なんですねー。

外食は社内での作業では味わえない唯一の楽しみです。

年末年始のお休みに突入

12月28日は出向先の仕事納めの日でしたが私はお休みとしました。
その為に前営業日である12月25日(金)にお世話になっていた常駐先の社員の方に挨拶を済ませた。
そして29日(火)は自社の仕事納め。
イベントは13時開始なのだけど駐車場が混むのを見込んで、また、自社社員さんと雑談をしたいので9時30分過ぎくらいに出勤。なんだかとってもマッタリしていました。

雑談でのお話。
私が1月末までに携わっていたプロジェクトが再度復活しそうとの事。
そのプロジェクトはC言語でDirectXをフルに使うモノだったりしまして、Sound関係のプログラム。
帰社した際にプログラムソースを眺めたけど立派なC言語のプログラムだ。
それを私が作ったなんてにわかに信じがたいけど私が作ったんだな。

まだ本格的にプロジェクトが復活するかどうかは未定なんだけど、定朝の話を聞く限りでは復活は濃厚だそうだ。
ご協力頂いた数学者の方にも再度参加していただけそうな様子だし。

ということで、来年からはもしかしたら、定時間内は常駐先での作業で、定時以降は(帰社して)自社での作業となるかもしれない。

常駐先での携わっているプロジェクトで使用している言語は(未だに)Visual Basic 6.0で、自社はC++。
複数言語がごった煮するけど、脳を切り替えて何とか対応したいですね。

ということで、皆さま、よいお年をお迎えください。

禁煙92日目

禁煙を開始して90日を超えました。ほぼ3ヶ月です。
まさか3ヶ月も続くとは,正直思っていませんです。

まだ,タバコを欲する時がありますが,決して吸いません。面倒だし。
そう,最近は喫煙が面倒と思えてきている。
いちいち喫煙所に行かないとだめだし。喫煙すると服に臭いが付着するし。

臭いで思い出した。タバコ臭のないスーツは初めてかもしれない。
今までは少なからずタバコ臭はあったけど,殆ど臭いは無い。おかげで同乗者
や家族には好評です。

保険会社によっては,非喫煙者の毎月の保険料が割引になったりするみたいで
すが,日本の大手保険会社は決してしないでしょう。なぜなら,生保会社の上
層部が喫煙者だからです。喫煙率を高くしているのもそういった上層部だった
りしますからね。

さてと,ここ2カ月ほど仕事が暇している状態です。社内失業とでもいいましょ
うか。既に何名かの協力会社さんが撤退して別の仕事をしている状態。

この先どうなるのだろうか。先が見えない。

かまってちゃんと愚痴

今いる現場の社員さんに,独り言,愚痴が多い人間がいる。

「暑い〜」
「仕事したくね〜」
「やりたくね〜」
「かったるい〜」

うるさい!!!!

大人なら黙っておけ。そう思っても口に出さないのが大人ってものだ。

ただ,普段の仕事からしてかなりのかまってちゃん的な性格なんだろうね。
あらゆることでオーバーアクションすぎるのだ。
よくもまぁ,これで仕事が務まるよね。

と,私もあまり愚痴を書くのはやめておく。

Microsoft Office 2007を使ってみて

Office2003に慣れ親しんだユーザーがOffice2007,特にExcel2007を使うと,そのインターフェースやらメニュー,ツールバーの配置/レイアウトが大きく変貌しているので,使い勝手が悪いと酷評でした。

個人的にOffice2003からOffice2007に乗り換えてみて,現在は2007を中心に使っています。
Office2007導入当初は違和感ありありでしたが,使えば使うほど良くできてるなと感心してしまいます。
2003以前は「慣れ」ということもあって目的の機能を出すのにそう苦労をしませんが,2007は以前のOffice製品に慣れていなくても使いたい機能がまとまっているのでとても便利です。
(それが逆に玄人を苦しめているともいわれますけど)

と,昨日のニュースで,次期Officeはインターネット経由での利用となるようで,しかも無料ときたものだ。
Googleに対抗するためだそうだが,今まで高いお金を払って使ってきたユーザは何なんだろうか。

もっとも,Officeと同等の機能をもったアプリ「OpenOffice」は無料で入手できるけど。

検索でヒット率が多いもの

SQL Server 2000 Japanese_CI_AS Japanese_BIN でヒットしていますね。
(ヒットしたからと言って閲覧されているかどうかは不明ですが)

どういった意図を持って調べているのかはわかりませんが,少なくとも仕事上・業務上で情報を得るために検索しているのでしょう。

ということで,私が携わった案件でのトラブル回避の内容を含めて照合順序の事を書いてみます。

Japanese_CI_ASは,SQL Server をインストールするときの標準設定でして,大文字小文字を区別しない物です。
つまりは,「'a' = 'A'」。MS Access 等がこれですね。大文字小文字を区別してない。
一方,Japanese_BIN は大文字小文字を区別します。だって,aのバイナリコードとAのバイナリコードは違いますから,よって,「'a' <> 'A'」。ODBC接続を使い,Accessを使ってJapanese_BINのデータベースに接続すると,大文字小文字を区別しますという警告メッセージが表示されます。

どちらが親切か,便利かは一概には言えません。だってそれぞれのシステムで目的に応じた照合順序を指定して稼働しているのだから。

で,以前の私のブログに記述したのは,master等の,SQL Serverシステムが使っているデータベースの照合順序がJapanese_CI_ASで,ユーザー作成データベースがJapanese_BINで,こういった環境で,SELECT句に,Case文を用いて等号不等号を使って値を比較していると不具合が発生するとの事でした。
(環境セットアップ手順書には,しっかりと「Japanese_BIN」とするように明記されているので,開発環境を作った輩の責任です)
照合順序云々というエラーですけど,要約すると,「アルファベットの『A』とひらがなの『あ』は,どちらが偉いか」。という,決着のつかないエラーをしているわけです。
決着がつかない,つまりはどちらが偉いのか甲乙つけられない,比較できないとの事でエラーとなります。

使うデータベース毎にユーザーを切り分け,そのユーザーのデフォルトデータベースを割り当て,直接そのユーザーテーブルを見れば良いのですが,私が担当したシステムで使っているログインIDが「sa」。「sa」というIDは,SQLServerでの管理者として設定されている特殊なID。このIDのデフォルトデータベースがmasterとなっている。

プログラム側で作成するSQLは,テーブルまでフルパスが区切ってあります。
例) UserDB.dbo.T_UserList など。
直接指定しているように見えますが,これ実はいったんmasterテーブルを経由してからユーザーテーブルに行っているわけですね。なぜなら,接続する際にsaユーザーを使っていて,そのユーザーのデフォルトデータベースがmasterです。なので,masterを経由する時点で照合順序がJapanese_CI_ASとなってしまうのです。

一方,ユーザーテーブルの照合順序はJapanese_BIN。照合順序がシステムデータベースとユーザーデータベースで違っていても,単純な抽出なら問題無い事を確認済み。UpdateもInsertもDeleteも大丈夫。単純な処理ならですが。

ストアド・プロシージャを使った処理は怪しいかな。私が担当したシステムには,幸いにもストアド・プロシージャを使った処理がありませんでしたが,それを使っている他システムでは何らかの不具合が発生していると聞いています。

これを避けるため,一時的・暫定的な対応としてなのですが,照合順序をJapanese_BINとしたデータベースを作成(仮にJ_BINとする)しました。テーブルその他はシステムが自動生成するものだけ。

つまりは空の状態。そして,saユーザーのデフォルトデータベースを「J_BIN」と設定。こうすることで,上述してあるような等号不等号を使ったSELECT句でもエラーが回避された。
ただ,ただである。これはあくまでも暫定対応。データベース構築失敗したのなら,再構築するのが本来の正しい方法(当然バックアップは必須)。

SQL Serverの再インストールで,インストール時に照合順序を間違わなければ無問題。
SQL Serverをアンインストールせずに照合順序を変更できるのですが,既存のユーザーテーブルが消える(正しくはリンクが消える)し,変更するにはインストールディスクが必要になるので,上述したけど再インストールの方が,余計な手順や余計な事を考えずに済むのではるかに楽です。

SQL Server 2000 の照合順序1

今の開発環境には,SQL Server 2000 が4台あります。
とあるSQLを実行したのですが,4台中1台のみSQL実行エラーとなる。

何故だ!何故なんだ!SQLは同じだし,テーブル構造も同じ。なのにたった1台だけエラーとなってしまう。

そのエラーとなるサーバ。
テーブルを参照する際に,「hogehoge.dbo.hogeTBL」とフルパスを設定している。
クエリアナライザで,データベースを「hogehoge」と指定してSQLを実行するとエラーとはならないが,「master」と指定してSQLを実行するとエラーとなる。

原因を探ると,どうやらそれはSQL Serverの「サーバー照合順序」が関係するのではないかとの結論に達した。

4台のうち3台は「Japanese_BIN」,残りの1台は「Japanese_CI_AS」。

その1台の「master」のサーバー照合順序は「Japanese_CI_AS」,「hogehoge」のサーバー照合順序は「Japanese_BIN」。
つまりは,直接データベース「hogehoge」を指定すれば「Japanese_BIN」となるが,「master」のままだと「Japanese_CI_AS」→「Japanese_BIN」となるのであqsws@@dそいれあr@じゃせふじこ

まて,今まで他の案件や改修で,こういった状態でテストしてきたんだよね。何故不具合が出なかったの?

今回,たまたまSQLのSELECT句内に不等号を使う式があり,それでエラーとなったわけだが,つまりは今までそういった処理が無かったってことなんだね。

本番環境が「Japanese_BIN」なら今回の不具合は発生しない。
本番環境をまだ確認したわけではないが,仮に「Japanese_CI_AS」だったら事態は深刻。上長に相談しなければならない。
→本番環境は「Japanese_BIN」でした。一安心。

データベース「master」の再構築をすれば良いようだが,ユーザ情報等が消えるようだ。
と,他の方々も使っているこのサーバー。使えなくなることは避けたい。
ということで,とりあえずその場しのぎではあるけど回避方法。
Japanese_BINのデータベースを新規作成し,通常ログインするユーザーのデフォルトデータベースをその新規作成したデータベースとする。
こうすることで,Japanese_BIN→Japanese_BINと照合順序は変更されないので無問題で処理される・・・・・・。と思う。

担当の方には,「あくまでもその場しのぎの方法。根本的な解決ではない。」事を伝えておいた。
今の作業が落ち着いたら,サーバー再構築だな。OSから。

Session変数の無駄遣い1

既存プログラムを元に新規プログラムを作っているわけですが,解析した結果,とんでもない処理をしているんですね。
当記事のタイトルにもあるとおり,Session変数の無駄遣いです。

帳票を出力する際,データベースからデータを抽出し,そのデータを基にXMLを作成しているのですが,なんとそのXMLのソースがファイルではなくてSession変数,つまりはサーバー上のメモリに展開しているのです。
メモリ上なのでプログラムが終了すれば跡形も無く消えるわけで,デバッグを難しくしている。
Session変数は,接続するクライアント毎に設定されるわけで,接続するクライアント数が多ければ多いほどSession変数も増える。
クライアントが少なければそれほどサーバーの負荷とはならないけど,エンドユーザーの環境はWebサーバーに各クライアント端末が接続して作業を行うわけで,クライアント端末は10台以上です。
サーバー側もラックマウントのサーバーですけど,積んでいるメモリにも限界があるだろうし,何故こんなつくりにしたんだろうかとつくづく疑問に思う。
せめてHDDにファイルを作成し,それを帳票側プログラムで読み込むとかすればよいものを。
先に投稿した記事にもあるけど,1プロシージャが3,000行もあるなんて異常だし,いったい誰がこんなつくりにしようと決定したのだろう。作った人の脳を見てみたい。

作り直したいけどそうはいかず,インターフェースは保持したまま行うしかない。

1泊2日のお仕事です。

昨日〜本日にかけて,泊りがけの仕事でした。
同じ青森県内なのですが,翌日,すなわち本日は朝一で作業現場に入らないといけない。
本社から車で2時間以上かかり,前日の作業が遅くなることが考えられたので宿泊となりました。

ビジネスホテルに泊まるのは久しぶりです。
東横インに泊まったのですが,このホテルはペイチャンネル,すなわち有料放送が無いのですね……。DVDやらISOイメージやらを持ってくればよかったよ。

そして,昨日は22時30頃までの作業,翌日は意外とすんなり作業完了。それでも朝8時に入って16時30分頃までかかりましたが。

そして帰路です。
青森県には八甲田山がありまして,この山は今の時期,残雪があります。
この時期,山道を通るのはなかなか勇気がいるのですが,ライブカメラを見る限りでは雪が無かったので山道走行が決定。

八甲田山録


まだ雪が残っています。
というか,青森県は,4月26日に降雪がありましたよ。

と,仕事が一段落し,帰宅。勝利の美酒を味わっています。

知人がDQNだとね1

少々愚痴っぽくなってしまう。

知人は,典型的な地方のDQN女。
でき婚からはじまり,今はその夫とは別居状態。
でき婚を悪いとは言っていないが,所詮それがきっかけで結婚したわけだ,相手の良し悪しを知らないうちにな。ふっ,結局別居かよ。とっとと離婚しちまえ。
知人には子供は二人居る。その子供がダメだ。子供だからというレベルではない。仕付けがなっていなく,特に食事時のマナーは最悪。
食事前「いただきます。」,食事後「ごちそうさまでした。」が言えない。言わない。
私の子供のほうがまだしっかりしているぞ。自分の席でしっかりと「いただきます。」「ごちそうさま」が言えてるのだからな。

車の運転もDQNそのもの。
シートベルトを着用しない。着用しない理由を聞いたら「面倒だから。」
そうか,面倒か。

 事故って車外に放り出されて車の下敷きになって死んでしまえ!
 脳挫傷で死んでしまえ!
 全身打撲で死んでしまえ!

違反となるから着用するのではなく,万が一の時に自分のみを守る為の物なんだけどな。
ちなみに,知人はシートベルト未着用で2回ほど検挙されていますが,長距離移動時以外は未だに未着用。学習能力=ゼロ。青森県警に通報してしまおう。
片手運転の常習犯でもある。右腕をハンドルの中央,左手は肘掛へ。
そんな状態で隣に乗る知人母とおしゃべりに夢中。今までよく事故を起こさなかったな。
正直,知人の運転する車には乗りたくない。見ていて怖いのではない,イライラするからだ。
まっ,所詮「井の中の蛙,大海を知らず。」状態。首都圏で運転したら事故を起こすのは間違いない。

お金が無いといいながら,10,000円以上もするカバンや服を通販で買う。
いったいいくつのカバンがあるのだろうか。というか,使えるカバンが1つあれば事足りるじゃないか。
常に携帯電話でネットしている。お金が無いなら,そういったところでコストダウンをしろよ。
私だって携帯電話をパケット定額上限まで使いたい。が,可能な限り使わないようにしているのだよ。

知人は「機能美」という言葉を知らない。知らないが為に,最新のデジカメをデコしてしまった。
呆れて物が言えない。
デコを否定するつもりは無いが,義妹のデジカメのデコは,誰が見ても「やりすぎ」状態。

他にも色々と言いたいことはあるが,強く文句を言えないのが現状。
私の子供の面倒を見ていただいたりしているので,「その点」は感謝しているが,それだけの事。

知人には一度,普通の会社で勤務していただきたい。
社会的な常識が欠如している,義妹は。

ダメだしされてもそれを肥しに反省しようとせず,怒りにしか変わらない。
Amazon
Profile

ぴろたん

Monthly Archives
livedoor 天気
Access Counter
  • 今日:
  • 昨日:
  • 累計:

訪問ありがとうございます。

ASPアクセス解析
  • ライブドアブログ