アーカイブ

2009年05月

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から。
1

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

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

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

カテゴリ:
普段愛用しているSoftBank携帯911Tが壊れました。
電源が入らなくなりまして,どうしようもありません。

幸いにも,嫁が以前に使っていたVodafoneブランドの携帯電話があまっていたので,それにUSIMカードを挿入して代替としています。
(こういう緊急時にSoftBankやdocomoは楽ですよね。auはUSIMカード入替だけでは使うことはできませんから)

何故電源が入らなくなったか。原因はまったくわからない。
ネットで調べてみると,どうやら911Tで同じような現象に遭遇している方が多々いるようです。

とりあえず今度の土曜日にショップにもって行きますが,修理となった場合,内臓の電話帳やらデータフォルダのデータが消えてしまうみたいで,それが一番痛いですね。バックアップも何もしていないし。

というか,auを使っていた時に電話が故障するなんて一度も無かったんだけどさ,SoftBankのブランドというか品質がダメなのか?

まあ,いまさらグダグダ言っても仕方が無いので,修理に出します。

カテゴリ:
何故にあんなに早起きなんだろうか。
時刻は午前5時。突然急所に衝撃が走る!
何事だと思いきや,どうやら我が子が私の上にダイブし,足が急所に直撃したようだ。
当然ながらその時点で眠気が飛び,目が覚めてしまう。

私も昔はそうだったのだが,何故休日に子供は早起きをするのだろうか。
休みでうれしくて興奮する?いや,まだ私の子供はそんな事をわかる年頃ではないのだが。

でも,休日に早起きするとなんだか得した気分になりますね。
なんだかんだで「(休日専用の)子供の目覚まし時計」には感謝しています。
どうせなら平日も起こして欲しいのですけど,平日は平日で二度寝する(笑)

まっ,良いですよ。元気に育ってくれればね。それくらいは我慢しますって。

カテゴリ:
青森をはじめ厳冬期を迎える地域の人達は,車を駐車させる際にパーキングブレーキ(サイドブレーキ)を使わない人が多い。ATならシフトレバーを[P]にいれ,MTなら[1]か[R]に入れておくわけです。
これは,パーキングブレーキが凍結(正しくは,パーキングブレーキのワイヤーが凍結)して解除できなくなる恐れがあるからです。

でも,ここで疑問に思う。パーキングブレーキを使わないのは冬季だけならまだしも,通年使わない人が多いのです。冬季期間は上述したとおり凍結するおそれがあるので使用しないのは理解できますが,凍結の恐れが無い冬季以外でなぜ使わないのだろう……。

自動車教習所でそう習うのでしょうか。
仮にそうだとしたら,そう教える自動車教習所が信じられません。

ATにパーキングブレーキは不要という考えを持っている方も多いが,不要ならメーカーが装備しないわけであって,必要だから装備されている。

[P]はギアがかみ合ってロックするだけで,タイヤそのものを制動しているわけではない。パーキングブレーキは,タイヤ(ブレーキ)を制動する。

ちなみに,私の車はMTですが,冬季もパーキングブレーキを使用します。
だって,凍結するのってワイヤー内部に水分が入って,それで始めて凍結の恐れがあるわけですが,そう簡単に水分は入らないし。

北国の常識=北国以外の非常識

ちと言い過ぎかもしれないが,車に関しては私はそう感じる。

このページのトップヘ

見出し画像
×