2

いくつかのマシン上で実行されているアプリケーションがあります(大体2と言います)。このアプリケーションはネットワーク上に置かれた共有mdbを更新します。ユーザーは一度に共有mdbを更新しようとしますが問題は1人のユーザーだけが更新できます他のユーザーはそれを開くことができません。誰もがアクセスがマルチユーザー環境をサポートすることを提案することができますか?

編集:

TFormRoadAttribという1つの形式があります。

procedure TFrmRoadAttrib.FormActivate(Sender: TObject);
if dmTimeDomain <> nil then
   begin
     if not (dmTimeDomain.dbTimeDomain.InTransaction) then
     begin
       dmTimeDomain.dbTimeDomain.BeginTrans;
     end;
   end;

どこでdbTimeDomain=TADOConnectionそしてその価値は

'Provider=Microsoft.ACE.OLEDB.12.0;
Mode=Share Deny None;
Extended Properties="";
Locale Identifier=1033;
Jet OLEDB:Registry Path="";
Jet OLEDB:Database Password="";
Jet OLEDB:Engine Type=4;
Jet OLEDB:Database Locking Mode=0;
Jet OLEDB:Global Partial Bulk Ops=2;
Jet OLEDB:Global Bulk Transactions=1;
Jet OLEDB:New Database Password="";
Jet OLEDB:Create System Database=False;
Jet OLEDB:Encrypt Database=False;
Jet OLEDB:Don't Copy Locale on Compact=False;
Jet OLEDB:Compact Without Replica Repair=False;
Jet OLEDB:SFP=False;
Data Source=Q:\BEL_01\BEL_GADM\ACCESS\Restrictions.mdb;
Jet OLEDB:System database=C:\Program Files\Tele Atlas\Common Files\DPT.MDW;
User ID=dbadpt;
Password=dbadpt;

下記のコードが実行されます[Ok]ボタンをクリックすると

if dmTimeDomain <> nil then
 begin
      if (dmTimeDomain.dbTimeDomain.InTransaction) then
            dmTimeDomain.dbTimeDomain.CommitTrans;
     end;
end;                                                                

親切にお勧めします。


  • delphiタグを削除してください。それはあなたの癒しには当てはまらず、役に立ちません。 - Steve Jorgensen
  • ユーザーの1人がDelphiアプリケーションを使用しているとどうなりますか?知るのに十分な情報が提供されていませんが、Delphiデータアクセスレイヤに何か問題がある可能性があります。実際、下のコメントを読んだ今、これはまさにその通りです。 Delphiタグは確実に属していますが、Delphiの人々がオプションが何であるかを理解できるように、Delphiコードも必要です。 - David-W-Fenton
  • トランザクションを制御するDelphiコードを投稿してください。それが問題の原因である可能性があります。 - David-W-Fenton
  • 私は私の質問の説明欄を更新しました。 - anshul
  • 接続文字列で定義されている接続モードは「共有拒否なし」です。共有mdbでは、「共有」に設定されています。接続文字列のモードを「ReadWrite」に変更した場合。それからエラーが来ています。 - anshul

3 답변


4

アクセスは確かにマルチユーザー環境をサポートしますが、あなたの許可は正しく設定されなければなりません。すべてのユーザーは、データベースが配置されているディレクトリにファイルを作成できる必要があります。また、すべてのユーザーは、そのディレクトリに他のユーザーが作成したファイルを変更する権限を持っている必要があります。それを台無しにする多くの方法があります。これは、Accessが同時マルチユーザーアクセスを管理するためのメカニズムの一部として別の.ldbファイルを使用するためです。

1人のユーザーに共有ディレクトリにテキストファイルを作成させ、もう一方のユーザーがそのファイルを開くことができることを確認してから変更を保存することをお勧めします。


  • ありがとうSteve.Butこれは問題ではありません。すべてのユーザーがネットワークドライブにフルアクセス権を持っています。1人のユーザーがmdbを閉じると、別のユーザーがそれを開いて更新することができます。 - anshul
  • 両方のユーザーがデータベースを直接開くのか、それともリンクテーブルを介して開くのか。直接の場合、どちらのユーザーも&quot;排他的アクセスのためにデータベースを開こうとしていないことを確認してください。また、許可設定は複雑になる可能性があるので、私が提案したテストを実行することをお勧めします。ユーザがディレクトリへのフルアクセス権を持つことは可能ですが、ディレクトリ内の1人のユーザによって作成された新しいファイルが他のユーザによって変更不可能であることは可能です。 - Steve Jorgensen
  • これは興味深いかもしれません:office.microsoft.com/en-us/access-help/…。アプリケーションがバックエンドデータベース内のオブジェクトの変更を許可する可能性はありますか? - Fionnuala
  • 「クリーン」でテストする価値があるかもしれません。フロントエンド。これは、単純なフォームと1つまたは2つのリンクテーブルを持つAccessフロントエンドです。各ユーザーにコピーを持ち、問題がまだ存在するかどうかを確認してください。 - Fionnuala
  • ユーザーが共有mdbにアクセスするとトランザクションが開始され、そのトランザクションがコミットされるまで他のユーザーは共有mdbを更新できません。それはその期間ロックされているためです。アプリケーションはinittransを使用しているDelphiで、committransです。このトランザクションがいつ完了するのか、またはmdbがロック解除されるのかを知る方法はありますか。注:すべてのユーザーが、個々のアプリケーションを実行しているのは、共通のmdbだけです。 - anshul

1

どちらもアプリを使用できるはずです。 1人のユーザーがフォームまたはテーブルを編集している場合、他のユーザーはそれらの同じオブジェクトを編集できなくなります。しかし、それが「プロダクション」状態になると、それはアプリに何の影響も与えないはずです。数年前、私は大きなアプリをMS SQL Serverバックエンド(MS Accessフロントエンド)に変換するのを手伝っていましたが、それまでは15人のユーザーで同時にアプリを使用することに成功していました。アプリが大きくなりすぎた(100フォーム、100テーブル、数百万行あるもの)ので、パフォーマンス上の理由から移動しました。そうでなければ、彼らはまだ完全にAccessにいるでしょう。


0

通常のアクセスmdbファイルの代わりにAccessプロジェクト(拡張子adp)を使用することを検討してください。アクセスプロジェクトはSQL Serverデスクトップエンジンと連携して動作します。これはOffice CDに個別のインストールファイルとして含まれています。これは本質的にあなたが走っているSQLサーバのわずかに水を入れたバージョンを持っていて、このサーバがあなたのためにすべてのあなたの同時並行性の問題の世話をすることを意味します。また、DBがAccessプロジェクトには大きくなりすぎる場合は、DBを本格的なSQL Serverマシンに簡単に移植できます。ストアドプロシージャなど、SQL ServerでできることのほとんどをAccessプロジェクトで行うことができます。セットアップや接続は非常に簡単です。


  • Steve Jorgensenの回答に対するコメントによると、フロントエンドはAccessではなくDelphiアプリであるため、これは不適切な提案です。 - David-W-Fenton
  • また、ADPとして2つのアプリケーションを作成しましたが、お勧めしません。 ADPは解決するよりも多くの問題を引き起こします。 - Steve Jorgensen

リンクされた質問


関連する質問

最近の質問