Filemakerの操作方法についての質問です。

たとえば、文書管理を目的としてデータベースを構築しており、マイクロソフトワードのファイルをオブジェクトとしてレコードに貼り付けたとします。

その後、なにかの拍子で、そのオブジェクトを選択した状態で、バックスペースキーを押してしまい、オブジェクトが削除されてしまいました。

これは復活できないのでしょうか?

これでファイルが消えてしまうとすると、データベースとしては致命的な気がします。

回答の条件
  • 1人2回まで
  • 13歳以上
  • 登録:2010/07/22 17:59:34
  • 終了:2010/07/29 18:00:06

回答(1件)

id:alpinix No.1

あるぴにっくす回答回数615ベストアンサー獲得回数972010/07/23 19:10:41

ポイント60pt

>いずれにしても、有益な回答を頂いているのですから、回答欄になんでもいいので(「あ」だけでもいいので)かいていただけませんでしょうか?

質問者の意向に沿って書き込みさせていただきます(自分も似たようなパターンは経験あるので)。

 

とはいえ、何も追記情報を書かないのもあれなので・・・

 

>いやいや、ゴミ箱機能を作ってくれればいいってことでよ。そうすればバックスペースキーを誤って押したくらいではファイルが完全に消えてしまうということにはならないでしょうし。ゴミ箱がたまってきた段階で空にすればよいわけで。

 

使い勝手としてはSharePointServerに近いですね。データベースソフトではなくファイル共有ソフトですが。

 

データベースソフトとしての使い方としては、データを削除するのは管理者にしか基本権限はないです。また削除行為自体、通常は管理者でも許さないことが多いと思います。(テーブルを跨いでリンクしているデータの整合性がとれなくなる)

 

>その2:やっぱりリンクの方がよさそうですかね。そっちのほうがデータベースが安定しますかね?

「リンク先ファイルを開くスクリプトボタンをレコード内に配置しておけば汎用性も操作性も高くできます。」の意味がまだ理解できないレベルですが。。

100MBのファイルを貼り付けるくらいなら、リンクでつないだ方が賢明かと。反応速度が違ってきます。

 

リンクでつないだ場合、ファイルパス情報をレコード内に持つことになると思いますが、FMは簡単にスクリプトが自作できるので、その「ファイルパス先を開く」コマンドを自作し、ボタンとかショートカットに割り付けておけば、質問者の望みの機能は果たせるのかな、という意味です。V11は持っていないし私自身しばらくFMからは離れているので、詳細な説明はできないのでここから先は悪名高い付属マニュアルを参照するか、使い勝手のいい入門書を購入して学んでください。

 

リンクで作った方がいい理由は先のコメントにも書きましたが、FM抜きにして文書管理をする上で重要なのが原本管理と版管理ですが、元データを元データのまま保管することで、こちらは担保できます。(電子データなので、バージョンアップやフォントの問題は付いて回るけど)

 

なので機能面、仕様面、両方からリンクで作った方がいいのではないかな、という意見です。詳細に全体仕様を見ているわけではないので参考までに。(ただ100MBのPDFやワードファイルを貼り付けるといった使い方はFMではあまりしないかと。仮にやるならFMServer買って本気でストレージ組まないとパフォーマンスも安定性も悪いでしょう)

 

 

id:draftand

ありがとうございます!v11はオブジェクトのリンクだけをはりつける機能がそもそもついているのでスクリプトはいらないみたいですよ。

文書管理で原本管理と版管理が重要なのはまったくもっておっしゃるとおりですが、なんかいいDBはないもんですかね。

2010/07/24 10:46:53
  • id:alpinix
    直接の回答ではないのでコメント欄で失礼します。
     
    それは質問者が管理者モードで作業しているからじゃないのでしょうか?
    実運用だとユーザーに削除権限なんて付与しないだろうから、レコードの削除はおろか、一度貼り付けたオブジェクトの削除やデータの修正も許さない仕様にするだろう。
    まあ、冷静に考えればFilemakerで文書管理(それも埋め込みオブジェクト)をしようという考えの方が致命的だとは思う。FMは悪いソフトではないが、その使い方では原本維持も版管理もできないので文書管理の用途にそぐわない。
    (最新VerのFMを持っていないので細かい方法とか突っ込まれても回答できないからブクマでコメントだけがいいかと思ったが、他にも関連した質問いっぱいしているユーザーさんなので、おせっかいと思いつつコメ欄汚し失礼します)
  • id:draftand
    なるほど、致命的なのはぼくでしたか(笑)。
    ただ削除したものを元に戻せるという機能はあってほしいですけどね。
  • id:alpinix
    >ただ削除したものを元に戻せるという機能はあってほしいですけどね。
    一長一短だと思いますよ。たとえばXPでゴミ箱を空にしても元に戻せる機能がついていたとします。
    その場合、HDDはゴミとして捨てたはずのデータも保管し続けなければならず、保存データはどんどん肥大化してHDDを食いつぶします。結局削除したデータをホントに削除するボタンが必要になる・・ということにもなります。
     
    データベースでも同じことで、一度登録したものを削除できない仕様では(今のFMの壁が何Gか知らないですが)単一のDBファイルの容量がどんどん肥大化してしまいます。これでは効率が悪い。最悪DBファイルそのものが壊れてしまいます。
     
    なもので普通は「削除したものは元に戻せない」がデフォルトで僕はいいと思っています。マシンに無限にリソースがあるのならいいのですが。
     
    http://filemaker-ml.jp/index.html
    おせっかいついでに。
    その1
    管理人が代わったようですが、恐らくまだ国内最大規模のMLです。FMの技術的な相談事ならこっちの方が回答がつくかもしれません。ただしガチの技術系MLなので、はてなみたいにフリーな話題を投稿すると反応してくれない(大人のスルー)こともあります。
     
    その2
    「文書管理」が目的なら埋め込みではなく、リンクで作る方をお勧めします。理由は先のコメント+DBファイルを出来る限り軽くできるためです。リンク先ファイルを開くスクリプトボタンをレコード内に配置しておけば汎用性も操作性も高くできます。 
  • id:draftand
    いやいや、ゴミ箱機能を作ってくれればいいってことでよ。そうすればバックスペースキーを誤って押したくらいではファイルが完全に消えてしまうということにはならないでしょうし。ゴミ箱がたまってきた段階で空にすればよいわけで。

    その1:私のようなわがままな質問者にはちょっと向いていないかと。

    その2:やっぱりリンクの方がよさそうですかね。そっちのほうがデータベースが安定しますかね?
    「リンク先ファイルを開くスクリプトボタンをレコード内に配置しておけば汎用性も操作性も高くできます。」の意味がまだ理解できないレベルですが。。

    いずれにしても、有益な回答を頂いているのですから、回答欄になんでもいいので(「あ」だけでもいいので)かいていただけませんでしょうか?
  • id:windofjuly
    うぃんど 2010/07/25 03:26:01
    管理者であっても普段は利用者向けの権限で作業するのは至極当然な対応だったりするのですが、いずれにしても間違ってキーを押したのであればたいていの場合は「元に戻す」だけの話だと思います

    画像や文書はリンクにしておけば、FileMakerとAdobeReaderのバージョンの組み合わせあるいはインストール順によって不具合を起こす(v11についてはまだよくわかりませんので回答していません)といったような様々な環境問題への心配も少なくなりますし、データとシステム部分が切り離されてるため、ベースのシステムが破綻しても画像や文書はそのままの形で残ります
    システムのアップデートやFileMakerとは内部の仕組みが違うAccessやMySQLなど他のデータベースへの移植も簡単にすみます
    バックアップもファイル単位で行うほうが簡単ですし、ファイル単位であればFileMakerではなくバックアップ用のソフトなどを使うこともできますので、短時間かつコンパクトに差分を得ることが可能になります

    画像や文書などの管理が目的であるならばノーツなどの文書管理向けのデータベース(お望みのゴミ箱もありますよ)を考えたほうがよろしいでしょう

    最近Filemakerを使う機会が無く、さらにv11の機能はあまり把握していないので、今は回答を控えていますが、以上気になったのコメントさせていただきました(ほとんどalpinixさんと被ってますけど)

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません