2005年 9月 24日

PC復活

投稿者 by vulcan at 07:39 / カテゴリ: 駄文 / 0 コメント / 0 TrackBack

有楽町ソフマップのお陰でマザーボードとHDDが故障の原因だと特定でき、それらを交換して復活した。
旧HDDは結局普通には読み込めない状況だったので処分(データの吸い出しをする業者に頼めば5万円ぐらいでやってくれると言っていたが)。

▼続きを見る⇔折りたたむ▲

しかし、今回の一連の修理騒動で随分勉強になった。マザーボードのマニュアルや組み立てマニュアルを読み直しPCの構造を再確認することができたし、最近のデスクトップの情勢が分かったのも大きかった。特にCPUのクロック数とメモリのクロック、HDDのバスクロックの関係を担当してくれた有楽町ソフマップのY氏が親切に説明してくれ、また、今後カスタムアップする場合の指針も提示してくれて、非常に有意義だった。

2005年 9月 13日

修理に向けて前進

投稿者 by vulcan at 22:54 / カテゴリ: 駄文 / 0 コメント / 1 TrackBack

これまでの状況をSE殿と検討した結果、CPU、HDD、グラフィックカード、マザーボード、電源、メモリなど、要するに全部が故障していないとは言い切れない状態であり、個別にチェックするにも大変だということになった。

▼続きを見る⇔折りたたむ▲


一方、今、デルで3万円を切るデスクトップマシンが売られているとのことで、いっそのことそれを買うことを勧められた。

確かに、規格も新しくなってしまっているので、古くなってしまった規格のPCにこだわるのは得策ではないような気もするし、またどうせ今後も変わっていくのであるなら、3万円ぐらいのPCの方が後々のダメージが少なくてよいのかもしれない。

特に、今はPCゲームにふけるという時期ではないし。子供たちがもう少し大きくなったときにPCゲーム用のマシンを気合を入れて買えばいいわけだから。

というようなことで、PCを買い換える場合、おそらくHDDは新しい規格であるシリアルATAでの接続になっているだろうが、古いIDE接続のHDDをスレーブ接続できるのかどうか、使えるけど使われなくなる中古パーツを部品として買い取ってもらえないかどうか、そのあたりを調査するため、有楽町ソフマップに寄った。

いろいろ物色してみたところ、HDD、メモリ、グラフィックカードなどは古い規格も中古で売られており、安く上げられないでもなさそうだという感触を得た。

一方、本体一式としては、中古で2、3万円のものがあり、新品でもバーガーセットや牛丼セットなどが相変わらず売られており、安いので4、5万円だ。スペック的には、グラフィックボードがついていない(オンボードになっている)のと、メモリが少ない点が今のPCに劣っている。

つまり、HDDやCPUは多少速くなっているものの、グラフィックが劣るし、メモリも少ないので体感的には遅くなったと感じるかもしれない。

一通り物色が終わり、そもそもの目的であった2つの疑問を解決するために、買取窓口の兄さんに相談してみたところ、素人の要領を得ない説明にもかかわらず真剣に耳を傾けてくれた。やはり、状況的には先のSE殿と相談した結論と同じく、最初はHDDだったのだろうが、どれもが怪しい状況にまで陥ってしまっているようだ。

そこで、修理センターに持ち込んでとりあえず故障箇所を特定し、修理代の見積を見てから決めてはどうかと提案された。聞くと故障の点検は僅か2100円でしてくれるという。まあ、直してくれるわけではないのだが、2100円で診断してくれ、今の八方塞の状態から抜け出させてくれるのは非常にありがたい。

修理センターの担当の方も、これまた親切で分かりやすいアドバイスで、診断状況にもよるが修理代は2、3万円かかるかもしれないこと、それに対して、修理するぐらいならバーガーセットとかを買った方がいいのか、今のPCとバーガーセットを比較してどう思うかと聞いたところ、今のPCのスペックは十分現役で通用するし、グラフィックカードとメモリが今のPCが上回っているので、はるかに速く感じるだろうという感想を聞かせてくれた。したがって、修理の意味はあるわけだ(グラフィックカードとメモリが故障していたとしたら考え直さないといけないが)。

というわけで、非常に頭が整理された。早速修理の仮受付をお願いし、宅急便で送ることにした。

ソフマップという会社は世の中で絶対に必要な会社だと強く思った。

2005年 9月 13日

異常個所の特定に奔走

投稿者 by vulcan at 11:37 / カテゴリ: / 11 コメント / 0 TrackBack

ビープ音が鳴っていないことから、マニュアルが指摘しているようにCPUが認識できていない可能性、ネットで検索したところ、同じマザーボード(P4PE)の掲示板が見つかり、そこでは同様っぽい現象をメモリの交換で対処しており、メモリが壊れた可能性、また、CPUやメモリよりは壊れやすいらしいビデオカード、マザーボードが原因であることも否定できず、さらに、そもそもの発端であるHDDも故障と見るべきだろうし、CD-ROMも「サラサラ」と砂が転がるような変な音がする。

▼続きを見る⇔折りたたむ▲


そうした状況の中、会社のSE殿に相談したところ、意外な事実が判明した。

この2年半のうちに時代は随分進んでいたようで、CPU、メモリ、HDDなどは既に2,3世代前と代物となってしまっており、ビデオカードの規格も変わってしまっていた。まるで浦島太郎状態である。

つまり、とりあえずHDDなりメモリなり、ビデオカードなりを購入してきたとして、それらで問題が解決すればいいが、解決しなかった場合、購入した部品をニューマシン用として使う際に旧規格であることがネックとなるわけだ。

ということは、どれが原因なのかを特定することが、かなりリスクの高い作業となってしまう。

更に、今それぞれのパーツの規格は過渡期にあり、今後も今主流の規格がすぐに陳腐化してしまうらしい。まあ、今に始まった話ではないが、改めて、PCのドッグイヤーぶりにうんざりしてしまった。これでは、拡張性の高さを評価してデスクトップを購入したのに意味無いじゃん!まあ、ノートに比べて圧倒的に安い!というのが最大の評価事項だったわけだけど。

というわけで、使っていないメモリ(旧規格のPC2700)をSE殿に一晩借りることにして、メモリの交換で回復させられないかどうかを確かめることにした。メモリ以外のCPUやマザーボードといった容易にパーツを交換してみて原因を探れないようだとすれば、諦めて、中古部品として売却する方向性を探った方がいいのかもしれない。

帰宅後、とりあえず、メモリを抜いた状態で電源を入れてみると、異常を示すBeep音が鳴った。メモリがささっていれば正常とみなすのか、メモリの状態まで確認して正常とみなすのかは分からないが、少なくともBeep音が鳴らなくなっただけというわけではないことが確認できた。

また、CPUを抜いた状態で起動をかけたが、こちらも別の種類の警告を示すBeep音がなった。ということはそれまではおそらくCPUも認識していたのだろう。

借りてきたメモリに交換して、再度起動をかけるも状況は進展せず。

元に戻し、とりあえず起動をかけながらほったらかすことにした。すると、5分ほど後に、「カタン、カタン」とHDDを読み込みにいこうとする音が聞こえた。数分間隔で訪れるこの弱弱しい音は、生きていることを知らせるだけの無意味な動作に聞こえるが、数日前、『すっきりデフラグ』を行なって、調子が悪くなったときと同じ音がしている。

『なにか手がかりになるのではないか』と期待しつつ、子供たちが寝る時間になったので、自分も一緒に練ることにした。

【2005/9/13追記】
「カタン、カタン」という音だが、SE殿の話ではHDDが壊れたときの典型的な症状。ただし、ブートセクタが壊れただけで、データは死んでないだろうから、おそらく後で吸い上げることが可能だろうとのこと。

2005年 9月 12日

PC故障

投稿者 by vulcan at 00:02 / カテゴリ: 駄文 / 1 コメント / 1 TrackBack

数日前、WindowsXPの起動がおかしくなった。WindowsXPのアニメーションの前でこけてしまい、起動ディスクを入れろというメッセージが出る。この現象は毎回必ず出るわけではなく、2、3回に1回という頻度だった。

▼続きを見る⇔折りたたむ▲


なんかやばい動きだと感じたので、翌日も同じ現象が出るのを確認し、最も大事なデータだけは別のPCに退避させておいた。今思えば、その更に前の日、MovableTypeで日記を更新していたら突然フリーズしたかと思えるほど画面が固まったことがあったが、あれも予兆だったのかもしれない。

とにかく、毎回必ず起こる現象ではないこと、BIOSはどうやら正常なようであることから、WindowsXPの起動セクタの読込が甘くなっているのだろう、従って、HDDが壊れかけているんじゃないかなぁ、と思いながら、とりあえず久しぶりに『答えてネット』で質問してみることにした。

質問フォームに症状を書き、質問を出す前に同じ内容の質問が既出でないかどうか確認すると、結構同様の現象が報告されていた。それらの回答を総合すると、やはりHDDが死にかけているらしい。しかしどうしたらいいのかが分からない。示された回答は、メーカー製ならメーカーに問い合わせるようにというアドバイス、自作なら「それぐらい自己責任で解決しろ!」というきついアドバイス。自分も自作なので、叱責されるだけで大してアドバイスはもらえなさそう。

ということで、とりあえず『答えてネット』で質問するのはやめて、会社のSEに意見を聞いてみることにした。

その前に、自分のできることをしようと思い、まずは、システムの復元をしてみる。しかし、症状は変わらない。というか、このころは、症状が悪化しており、5回に1回ぐらい起動でき、あとはWindowsXPのアニメーションの前で止まってしまう。

そこで、デフラグをかけてみようと考える。標準で用意されているデフラグはWindowsXPが起動した状態なので重いため、フリーのデフラグツールでWindowsXPの起動前の状態でデフラグさせたほうがいいと判断した(これが思いっきりうらめった)。

デフラグをする前に、システムのチェックを行なうのだが、その間に何回か再起動が行なわれる。ところが、起動がうまくいかないので、何回もとまってしまい、そのたびにCtrl+Alt+Deleteで起動させたのだが、とうとう何十回やっても起動しなくなってしまった。

しかたなく、デフラグ中の最悪の状態で電源をブチ切りすることとなってしまった。

そういうことで、会社に行きSEに状況を話すと、HDD、BIOS、電源辺りがおかしそう、一番怪しいのはHDDだが、CDブートできるかどうかを確認すれば間違いなくHDDがおかしいことになるのでブートCDを分けてくれてこれを使って確認するようアドバイスをもらった。

その日の夜、帰宅前にソフマップに寄ってみると、中古のHDDが5,000円程度で売られていることが分かる。買おうかと一瞬思ったが、自分のPCのスペックもろくに覚えていない状況だったので、よく調べてから買うことにした。

そして今週末、「とにかく一度掃除をしてからつなげなおしたらどうか」という妻のアドバイスに納得し、ケースを2年半ぶりに(購入以来初めて)開けてみると結構汚れている(特にファン)。

HDDは汚れているといえるほどではないが、システムファンの吸気口がほこりでつまりかけていたので、熱でHDDがやられた(夏でもあるし)可能性も考えられる。

前面と背面のファンを掃除し、ついでに電源のファンとCPUファン、ビデオカードのファンを掃除。吸気口のほこりをとった。電源、ファン、CD-ROM、HDD、CPU、メモリ、ビデオカードなどを一度外して掃除した。

続いて、サーバーマシンも掃除しようと思い、こちらも2年ぶりぐらいにケースをあけた。さすがに毎日稼動しているだけあって、よくこれで動いていたなと感心するほど汚れていた。

ほこりを取り除き、先にサーバーマシンを組み立てなおして起動させようとするが起動しない。「ヤバイ!」と思ったが、よく見るとメモリを外したままになっていたので、メモリを指しなおし、再度起動させてみるとちゃんと起動した。

次に、壊れたPCの方も再度組み立てなおし、起動させると、起動した!

しかしながら、画面はいきなりBIOS画面。ちょっとやばい感じもしたが、1歳のHikaruがキーボードをバシバシ叩いていたので誤ってdelキーをおしたのかもしれない(爆)。

そして、BIOSを抜け、緊張していると、一発でWindowsXPの起動アニメーションが登場した。『やった、いやしかしたまたま一回だけかもしれないし』などと喜んでいいのか戸惑っていると、ログイン画面には行かず、(予想通り)途中で終わっていたデフラグの続き(システムのチェックの続き)が始まってしまった。長そうだったので、先にサーバーマシンをとりあえず完全に組み立てることにした。

そろそろ画面が切り替わったかなと思い、確認しに行くと、画面は真っ黒。一体どうなったのかが分からない。

以後、何度電源を投入しても画面は本体から何も信号を受け取らないようで真っ黒のまま。

なお、先のSEにもらったブートCDはこの時まで使うのを忘れており、だめもとで入れてみたが、画面に変化はなかった。

考えられるのは、ビデオカードが壊れてしまったか、BIOS、つまりマザーボードが壊れてしまったか、あるいは掃除の際にCPUをあけてしまったのはやっぱりまずかったのかもと後悔しはじめる。

八方塞を打開するため、当初のマニュアルと解説ビデオを見る。すると、起動させてもビープ音が鳴っておらず、この症状はCPUが認識されていないことを示しているようだということが分かる。

といって、CPUを認識させる方法も分からず、CPUもHDDも壊れてしまったのなら、買い替えた方がええんちゃうかと思いながら、とりあえず、明日再び会社のSEに相談してみることにして、暗い気持ちで後片付けをした。

2005年 9月 07日

Openステートメントの使い方

投稿者 by vulcan at 19:39 / カテゴリ: 駄文 / 0 コメント / 0 TrackBack

Openステートメントはテキストファイルを高速に読み書きすることができますが、データを抽出したり、一括して更新したりといった操作を行なう場合は、リレーショナルデータベースに対してADOでアクセスするやり方が適していますので、結局のところ、使いどころはテキストファイルの特性に引きずられることになるでしょう。

▼続きを見る⇔折りたたむ▲

したがって、一番オーソドックスな使い方としては、会計ソフト等から書き出したテキストファイルを整形し(勘定奉行の場合csv保存したファイルはデータとしてとても扱いにくい)、中間ファイルとして扱いやすい形で保存しておく場合が挙げられ、ここでOpenステートメントの真価が発揮されると思います。

Dim Buffer() As Byte, MyText As String
Dim i As Long, kugiri As Byte
Dim StDate As String, myDate As Long, KanjoNum As Long
Dim LineArray, myLineData, myData
    Open strPath & FileName For Binary As #1 'バイナリーモードで開く
    ReDim Buffer(LOF(1))
    Get #1, , Buffer      '一気にバッファに読み込む
    Close #1'ここまででBufferにファイルの情報がバイナリデータとして保存
    MyText = StrConv(Buffer, vbUnicode) 'ユニコードに変換
    LineArray = Split(MyText, vbCrLf) '行に分割する
    StDate = Mid(LineArray(0), 14, 11)'ここに年月日の文字列が存在している
    myDate = CDate(StDate) * 1'文字列を日付リテラル値に変換
    Open strPath & "部門別試算表DB\" & Format(myDate, "yyyymm") & ".txt" For Output As #1
    Open strPath & "全社試算表DB\" & Format(myDate, "yyyymm") & ".txt" For Output As #2
    kugiri = 1
    For i = 3 To UBound(LineArray) - 1
        myLineData = Split(LineArray(i), ",")'各行のデータをカンマ区切りで分割
        myData = Mid(myLineData(0), 2, 4)'文字列から数値部分を抜き出し
        If kugiri = 1 Then
            KanjoNum = myData * 1
            kugiri = 0
        ElseIf IsNumeric(myData) Then'小計の行以外は勘定コードか部門コードが入っている
            If KanjoNum >= 500 Then
                Write #1, myDate, KanjoNum, myData * 1, myLineData(5) * 1
            End If
            kugiri = 0
        Else
            If KanjoNum = 230 Then
                Write #2, myDate, KanjoNum, -myLineData(5) * 1
            Else
                Write #2, myDate, KanjoNum, myLineData(5) * 1
            End If
            kugiri = 1
        End If
    Next i
    Close #1
    Close #2
ちょっと、これだけ見ても何をやっているのかわかりにくいと思いますが、要するに、読み込むテキストファイルは1行目から3行目まではヘッダ情報があり、それ以降も、勘定科目を示す行があり、そこから部門別残高が1行から数行にわたって記されており、最後に小計が記載されて次の勘定科目のデータが続く、というように非常に扱いにくい状態のものを、テーブル形式に変換したい、というのが目的で、たいした負荷ではないのですが、なるべく速く、エレガントに処理したいということで、バイナリモードで一気に読み込み、Split関数で配列に落とし込み、各行毎にデータを加工しながら、その都度書き出すというやり方を取っています。

ミソは『スプレッドシートに展開する必要はない』という点です。

以前は、ADOで同様の操作をしていましたが(スプレッドシートへの展開は無し)、3倍ぐらい速くなった気がします(といっても1秒がコンマ3秒程度に縮まった程度ですが)。

参考にしたサイト
Excelでお仕事!
外部テキストファイルとの接続方法
テキストファイルを高速に読み込む
VBAの小技集

2005年 9月 07日

テキストファイルをデータベースにする

投稿者 by vulcan at 10:21 / カテゴリ: / 10 コメント / 0 TrackBack

どういうケースにおいてテキストファイルでDBを構築するのがいいのかを考えてみたいと思います。

▼続きを見る⇔折りたたむ▲

テキストファイルの特徴を挙げてみます。


  • 誰でもデータが見れる、誰でも書き換え可能

  • サイズが小さい

  • Openステートメントで高速読み書き可能

  • ADOでアクセスし、SQLの実行も可能

  • Schema.iniでフィールドの定義等可能

  • 他のアプリケーションの出力ファイルをそのままDBにできる

  • インデックス、主キーの設定がないので大規模データのSQL操作は不向き

こうしたことを踏まえ、実際にテキストファイルをDBとして扱っている事例を題材に、その適否を考察してみたいと思います。

会計ソフトが吐き出す各種のテキストファイルを加工してDBにするというのがあります。例えば毎月のBSやPL、キャッシュフローデータなど。これらは何のために吐き出すのかというと、レポートを作ったり分析をしてみたいからです。

会計ソフトのデータに直接アクセスできれば一番いいのですが、それはできないことの方が多いでしょう。したがって、自分たちの目的に適ったデータを出力させデータベースとするニーズが出てくるわけです。

しかしながら、自分たちの目的というのは、データの推移に意味があるのではないか、何かが言えないかといった『気まぐれの分析願望』であったり、言い訳資料、成果のアピールとしてこうした表がほしいといった『気まぐれの誇示欲求』であったり、会計ソフトが提供している帳票が細かすぎて見にくいので、少しだけすっきりさせたいという『ちょっとした工夫の欲求』であったりと、要するに本気で気合を入れてDBを構築するほどではないわけです。

もちろん、そうしたちょっとしたニーズが長年蓄積されて、定型的な月次報告様式や財務分析手法が確立され、それに適したデータベースを構築することにもなるわけですが、往々にして定型といいながらも月日の経過とともに随分変化してしまうものです。

結局、もととなる会計データベースを構築するわけではなく、そこから吐き出されるデータを、後に分析、加工しやすいように一時保管するというのがこの場合のDB構築の目的といえるでしょうから、こうした場合はテキストファイルでDBを構築するのに向いているのではないかと考えるわけです(手前味噌ですが)。

ただし、データの規模が膨大であったり、SQLの多用を想定しているのであれば、リレーショナルデータベースの構築を検討した方がいい場合があるかもしれません。

もうひとつの例として、例えば勤怠管理において、未承認データをテキストファイルで保持しておく場合があります。承認前のデータは各自がテキストファイルで作成し、承認後、DBへの登録は特定の権限を付与されたものが行ないます。

いきなり、未承認の段階で各自がDBに書き込みに行った場合、承認前なのかどうかの管理が複雑ですし、承認後に各自が書き換えられないような仕掛けを作るのも大変です。また、データベースへのアクセスが集中してしまうという問題も生じます。この点、各自別々にテキストファイルを作成する場合、アクセスの集中は回避できます。

他には、データの一時バックアップとしてテキストファイルを使ったり、他のアプリケーションで使うための一時的な中間ファイルとしてテキストファイルを使うということが考えられます。

こうしてみてみると、結局、テキストファイルは、その作成上の容易さ、高速さという武器を活かした、一時的、中間的データの保存に用いるのが良いように思います。

2005年 9月 07日

データベースを設計するということ

投稿者 by vulcan at 00:24 / カテゴリ: / 5 コメント / 0 TrackBack

データベースを設計するということは、小さな世界を構築することに似ていると私は思っています。

▼続きを見る⇔折りたたむ▲

その世界を定義し、訪れる人種、訪れた目的を想定し、世界に秩序を与え、自己完結的に永続させようとします。つまり、ある意味で神になった気分になれるわけですが、しかし、自分の技量不足のため、不細工で、不安定な世界が出来上がってしまいます。

いい世の中を作りたい、という思いで、新たに世界を構築しなおそうと、データベースの設計方法、インターフェイスの設計方法、データアクセス方法などを学びなおし、あれこれと模索するときは、非常に高揚しており楽しいのですが、しかしながら、多くの場合、いろいろ調べていくうちに、疑問の数が等比級数的に増えてしまって収拾がつかなくなってしまいます。

そんなわけで、経験上『いいデータベースを抜本的に作り直そう』などという目標がうまくいくことはないのですが、しかし、志が高くなければ成長も小さいわけで、目下、次の飛躍のためにあれこれと調べ物をしている次第です。

まあ、しかし、データベースとひとことで言っても本当に様々ですね。そして、万能なデータベースはない。適材適所が慣用ですが、そのためにはいろいろ知識が要る。となると膨大な未開拓領域を前にして、未熟な自分がほとほと嫌になってきます。

救いは、どこまでやるかは目的次第だということです。そして、目的は自分で決められるということです。相手があったり、クライアントがある場合もあるでしょうが、自分が関与することで、目的を誘導することもできないわけではありません。

仮に、目的によって未開拓領域を開拓する必要が生じた場合、これも、目的達成という命題のため、普段では考えられない力が発揮されるのも経験上明らかです。

逆に言うと、目的を明確にしないで開発に着手するのは危険です。しかし、目的を定める前に、あえて目的をあいまいにして、あれこれと可能性を探る期間を設けるというのも、大きな飛躍につながったり、思いがけない裏技を思いついたりするわけです。

データベースの設計は、特にそれがRDB(リレーショナルデータベース)である場合、後戻りはなかなか難しい、ということを肝に銘じて、じっくり取り組みたいものです。

2005年 9月 04日

Excelをインターフェイスにする方法

投稿者 by vulcan at 02:14 / カテゴリ: 駄文 / 0 コメント / 0 TrackBack

Excelは、その自由度の高さから、インターフェイスにとても向いていると思っています。つまり、開発が容易なのですが、更に機能も充実しているExcelですから、いろんなことがてんこ盛りのインターフェイスを作ることができます。また、印刷にも強いのも魅力です。

▼続きを見る⇔折りたたむ▲

Excelをインターフェイスにする場合、DBへのアクセスは、主流はADOになります。ADOはDBがmdbファイルである場合に限らず、csv、txt、xlsといったファイル形式でもADOで操作できますし、MSDE、MSSQLサーバーでもADOで操作します(こちらは未確認)。

他には『外部データの取り込み』でクエリ取得する方法が便利です。こちらはVBAを組まないでいいので、開発は一瞬で終わります。操作もAccessでクエリを作成するのと同じ感覚でできます。但し、データの取得のみで、追加、更新操作はできません。追加、更新が必要な場合にはADOでアクセスする(VBAを組む)必要があります。

他には、DBのデータを読み書きするだけであるならば(SQL操作をしないならば)、DBをcsvかtxtで作成してOpenステートメントでアクセスする方法が非常に高速でお勧めです。

このように、Excelをインターフェイスに選択すると、いろんな種類のDBに対応でき、しかも、DBへのアクセス方法も様々な手法を採用することができます。

また、Excelは、取得したデータを加工するのにも向いています。これは、スプレッドシートで式が使える、グラフ機能がある、解析ツールや最適化ツール等が用意されている、VBAがスプレッドシートに展開したデータを取り扱うことができるため非常に直感的にプログラムが組める、などの理由が挙げられます。

ADOによるDBアクセスにせよ、『外部データの取り込み』によるクエリ取得にせよ、常時同期を取り合わないことがメリットになります。mdeファイルをインターフェイスにした場合、DBがmdbファイル(Jetデータベースエンジン)であった場合、常時同期を取り合うために同時アクセスがあると非常に重くなります。おそらく多くの現場において、常時同期が本当に必要とされるケースというのはまれで、大抵は随時同期で足りると思います。そういう意味でも、Excelをインターフェイスにした方がニーズに相応したものが作れるでしょう。

ビジネスシーンにおいて、Excelファイルが読み込めないという状況は我が国では考えられないため、Excelをインターフェイスにすることのデメリットはほとんど思いつきません。強いてあげるなら、HtmlファイルやASPファイル、xmlファイルなどをインターフェイスにした場合と比べて、ブラウザの立ち上がりに比べて、Excelの立ち上がりは重い(ウィルススキャンされる設定だと)点ぐらいでしょうか。

Excelは同時に複数が開く場合、一人以外は読み取り専用となりますが、DBが別にあるため読み取り専用でも構いません。また、xlaファイルをうまく作りこめれば配布の問題も相当クリアできます。この点は、井上治氏のサイトが参考になります(後日自分も取り上げて見たいと思います)。

2005年 9月 03日

アクセスランタイム

投稿者 by vulcan at 02:22 / カテゴリ: / 18 コメント / 0 TrackBack

データベースを設計する場合、やり方はいろいろ考えられると思いますが、私の場合は、mdbファイルで作成し、AccessでDB設計&操作を行なうというのがオーソドックスです。

▼続きを見る⇔折りたたむ▲

ところがAccessでDBを設計した場合、データを利用する人(つまり社員)全員がAccessを導入する必要があるのか、という問題に遅かれ早かれぶち当たります。

ほとんどの多くの人はAccessをインストールしても閲覧のみ、せいぜいフォームからデータを入力するのみの利用であり、DBの設計を行なう人はほんの一握りでしょう。それなのに全員にAccessを導入するというのはいかにも無駄が大きいと感じられます。

そこでアクセスランタイムを導入するという手が考えられます。

最上位のOfficeXP Developerには再配布可能なアクセスランタイムが搭載されています。

アクセスランタイムとはAccessで作成されたmdeファイルを実行することができます。mdeファイルとはmdbファイルをDB最適化して変換したもので、VBAはコンパイルされてソースは消されており、テーブル、フォーム、レポート等は編集できず、テーブルに直接アクセスすることもできません。要するに、フォームとレポートのみ利用可能ですが、データの追加、更新、削除、印刷、マクロの実行等は十分行なえます。

そもそも、Microsoftも開発しない人にはランタイムを配布すればよいという設計思想のようです。

また、ネットで調べれば幾つかのAccessで作成されたアプリケーションはランタイム付で配布していることが分かります。ランタイムはそれぞれのアプリケーションに対応させてカスタマイズされているため(←推測)、どのランタイムでもいいとは限らず、目的のmdeファイルを実行するのに適したランタイムがどこで手に入るかは分かりませんが、根気良く探せば見つかる可能性は大きいと思います。

さて、ランタイムを使って、皆がmdeファイルをインターフェイスにDBにアクセスする方法ですが、DBがJetであるため同時アクセスはつらいです。というか、数秒間隔で常に同期を取っているのが負担大きいようです。

この対策として手軽なのはDBをMSDEにする手があります(まだ試したことありません)。但し、MSDEは同時アクセス5人までが推奨ですから、あまりに大規模な組織では太刀打ちできないかもしれません。ちなみにMSSQLサーバーは同時アクセス無制限のようです。

しかし、果たして本当に同時アクセス(常時同期)が必要なのかどうかは、一度良く考えてみた方がいいと思います。つまり、データベースはmde、インターフェイスはExcelもしくはデータアクセスページ(ここでもアクセスランタイムが役に立っていると思われます)というのもありだと思いますし、あるいはASP+IISといった選択肢も考慮に入れた方がいいかもしれません。

【2005/9/13追記】
アクセスランタイムはMDEファイルしか読めないという認識を持っていましたが、誤っていました。機能的にはMDEファイルを見る以上のことはできませんが、わざわざMDEファイルを作成する必要(手間)はないということがいえます。

Access Club 初心者 Forum


アクセスランタイムとは、AccessがインストールされていないPCでもAccessで作ったシステムを動かすためのものです。簡単にいうと、Accessの機能を制限したバージョンと思えば理解し易いと思います。
(機能制限とは、テーブル、フォーム、モジュールといったオブジェクトの変更を出来なくしたもの、つまり開発できないということです。)

2005年 9月 02日

データアクセスページは使えるか

投稿者 by vulcan at 16:35 / カテゴリ: 駄文 / 0 コメント / 0 TrackBack

Accessではデータアクセスページという機能があります。これは、mdbファイルへの読み書き操作をブラウザを介してやってしまうというもので、結構使えそうな気がします。しかし、ネットで検索してもデータアクセスページに関する情報は極端に少ないのが現状のようです。

▼続きを見る⇔折りたたむ▲

この情報の少なさは、おそらくデータアクセスページが『使えない』ことを示していると思われますが、なぜ『使えない』のかを自分なりに納得したい、もしかすると限定的に『使える』ケースが見つかるかもしれない、ということでちょっとだけ試行錯誤してみました。

実は昔、データアクセスページを使ってワークフローが作れないかと試行錯誤してみたものの、Accessが入っていないPCではブラウザ表示できない(ようだ)という現象にぶつかり諦めた、という経緯があります。なぜなら、全社員にAccessをインストールしてしまうなら、データアクセスページでしこしこデータにアクセスするよりも、みんなが直接Accessを開けばいい話だと思ったからです。

ところが、今回調べているうちに、Office2000がインストールされていればデータアクセスページを見られるという(未確認)情報を見つけました。また、データアクセスページはフォームなりレポートなりが作られていれば別名保存操作だけで一瞬にして作れてしまうということも分かり、俄然やる気が出てきたのです。

これは、どういう可能性が開かれたかというと、ちまちまVBAでソースを書かないでも、ほとんどのやりたいことはGUIを基本としたフォームの設計だけで開発を終えることができるかもしれないこと、そもそも、フォームやレポートが作られているシェアウェアソフト等を購入した場合、フォームの設計すら不要のため、別名保存操作だけという開発所要時間2分程度でデータアクセスページができてしまうという状況が考えられ、妄想がいろいろ広がってきたわけです。

そこで早速、フォームの別名保存によりデータアクセスページを作成してみました。これを、Accessの入っていないPC(Accessランタイムは入っている)で見たところデータアクセスページがきちんと表示され、データの操作ができたのです。Office2000が入っていて、Accessランタイムが入っていないPCでの実験はしていませんが、目下の自分のニーズではAccessランタイムでの動作確認が取れれば十分です。

これは大きな前進だと感じました。というのは、Accessランタイムでmdeファイルをインターフェイスにしてmdbファイルにアクセスするというのはプロジェクト全体の開発が完了していないといろいろ面倒なのに対して、データアクセスページは開発途上でもmde変換のような面倒くささがないこと、また、mdeファイルをインターフェイスにすると、数秒毎に同期が取られている関係で4,5人同時アクセスしたらかなり重くなってしまう(2人でも重いことは重い)のに対して、データアクセスページでは、ファイルを開いたときと保存ボタンを押したとき以外は同期が取られないため、多人数同時アクセスが非常に軽いというメリットがあります(同期が常時でない分、別の問題が生じる可能性がありますが)。

上記同期の問題は実験によって確かめました。mdeで2つのPCから同時アクセスすると片方が更新したらもう一方は何もしないでいると数秒後には画面が更新情報を反映していました。一方、データアクセスページで同時アクセスしても、片方の更新情報はいつまで経っても他方に反映されず、他方をいろいろ操作してみても同じで、ファイルを開きなおさないと更新情報を取得しないようです。
これでは、同じデータの同時書き換えで問題が生じると考え、試してみたところ、後から更新をかけようとした方は、既にデータが書き換えられているという警告情報が表示され、それでも更新を強行するかを聞いてくることが分かりました。したがって、ルールさえ明確にしておけば(警告が出た場合は更新をキャンセルするとか)大きな問題は生じないと考えています。


ということで、『一定のケースにおいてはデータアクセスページは非常に有効』という第一印象を受けたのです。

しかも、たまたま、ワークグループ管理のテストをしていたのですが、ワークグループ管理を行なってデータアクセスページを作成すると、ブラウザからDBにアクセスする際にID、PWの確認を行なうことも可能であり、セキュリティも低くならずにすみそうです。

テストでの感触としては、テーブルの更新操作、閲覧を目的とした場合には非常に有効な気がしました。

ただし、いくつか問題点が露見されてきます。

ひとつは、外部リンクを使っていた場合、外部リンク先のデータがあるフォームはデータアクセスページ保存できないという問題です。このため、データアクセスページにこだわるなら、外部リンクをなくすため、DBの大規模化を目指すか、外部リンクのデータを外部リンク先の変更時に自動コピーするようにし、コピーしたテーブルを用いてフォームを設計するかしなければならなさそうです。

さらに、データアクセスページの編集は非常に重いことが判明しました。これは、何か特殊な要因(バージョンの問題とか)が絡んでいるのかもしれませんが、現時点ではとてもまともには編集できないという状況です。したがって、フォームのうちに完全な状況にしてデータアクセスページで保存するしか手はなさそうですが、そうすると、ボタン等コントロールの設置ができないため、制約が大きくなってしまいます。

そして、ちょっと期待していたのですが、フォームのコントロールはデータアクセスページ変換してhtmlファイルとなった場合、コントロールとしては機能しないということも問題です。データアクセスページはデータアクセスページ用のコントロールが用意されていますのでこちらを使う必要があります。ということは、シェアウェアを買って、用意されているフォームを別名保存するだけという淡い夢はついえたことになります。

結局、データアクセスページの使い勝手はネットでの情報の少なさに比例しており、非常に限定的な用途として活路が開かれているに過ぎない、というのが現在のとりあえずの結論です(残念ですが)。

まあ、もう少し検討して、『こういう場合はデータアクセスページが最適』というのを見つけるとともに、何とかしてまともに編集ができる状態を模索したいと思います。

【2005/9/7追記】
データがネットワーク上にある場合、データアクセスページの編集は絶望的に重いですが、データも含めて自分のPC上において開発を行なえば、ストレスを感じない程度に編集が可能であることが分かりました。

この場合、共同作業は難しく、開発後にデータの移行作業が発生して面倒ですが、背に腹は代えられません。これで、ほとんど開発は不可能という状態からは脱しました。