3

Active Directory IDとは異なるユーザーとしてms-accessを（ODBCを介して）ms-sqlデータベースに接続するにはどうすればよいですか？

ODBC接続でアカウントを指定したくないので、ms-access側でアカウントを指定して、ユーザーからアカウントを非表示にします。ODBC接続でこれを行うと、回避しようとしている元の状況にすぐに戻ることができます。

はい、これは前の質問に関連しています：http: //www.stackoverflow.com/questions/50164/

4

6 に答える 6

5

「ODBC DSN-LESS接続」を使用すると、これを希望どおりに機能させることができると思います

必要に応じて、Windows 認証を使用して ODBC DSN をユーザーのマシンに保持します。データベースへの読み取り専用アクセス権をユーザーに付与します。(新しい mdb ファイルを作成してテーブルをリンクすると、データの読み取りのみが可能になります。)

データベースへの読み取り/書き込み権限を持つ SQL ログインを作成します。

リンクされたテーブルをループし、接続をリセットしてSQLログインを使用するVBAルーチンを作成しますが、必ず「DSNレス」構文を使用してください。

"ODBC;Driver={SQL Native Client};" &
       "Server=MyServerName;" & _
       "Database=myDatabaseName;" & _
       "Uid=myUsername;" & _
       "Pwd=myPassword"

このルーチンをスタートアップ コードの一部として呼び出します。

このアプローチに関するいくつかの注意事項:

  • 読み取り/書き込みから読み取り専用に変更し、データベース (mde/mdb) ファイルを閉じて再度開かずに読み取り/書き込みに戻そうとすると、接続情報に問題があるようです。起動時に一度これを読み取り/書き込みに変更でき、セッション中に変更できない場合、このソリューションは機能するはずです。

  • DSN - Less connection を使用することで、コード内でユーザーから資格情報を隠すことができます (mde ファイルを渡していれば問題ありません)。通常、接続文字列をハード コーディングすることはお勧めできませんが、社内アプリを扱っているので、この方法で問題ありません。

于 2008-09-30T14:14:16.913 に答える
0

統合/Windowsセキュリティを使用してみませんか。Active Directoryグループにユーザーに必要な権限を付与してから、そのグループにユーザーアカウントを追加できます。これに加えてSQLサーバーのロール機能を使用して、使用されているクライアントアプリケーションに基づいて機能を制限することもできると思います。

于 2008-10-17T07:43:54.753 に答える
0

@Philippe
私は、あなたが「認める」という言葉を、理解する、またはおそらく同意するのとほぼ同等であると使用していると思います。拒否の反対とは対照的に。

すべてのユーザーが1つのIDとパスワードを使用してデータベースにログインする（そしてそれらをアプリケーションに保存する）ことの意味を理解しています。それは私にとって、私が今直面している問題よりも小さなリスクです。
@オフ

問題の背景：WindwosNT認証を使用して各ユーザーワークステーションにODBC接続を設定しています。ほとんどの場合、ユーザーはMDEセットアップを使用して接続し、そのODBC接続を使用します。この場合、ユーザーは常にデータを追加/更新/削除することができます。

問題は、一部のユーザーがMS-Accessについて十分な知識を持っているため、新しいmdbを作成してMS-SQLサーバーにリンクできることです。その後、一定量の検証と手持ちを行うアプリケーションを経由するのではなく、テーブル内でデータを編集できます。そして彼らはこれをするのが好きです、しかし時々それを台無しにして私に問題を引き起こします。

于 2008-09-16T22:10:31.023 に答える
0

接続に使用するアカウントで MS Access プロセスを起動する必要があると思います。CPAUなど、これを可能にするさまざまなツールがあります。このツールを使用すると、パスワードも暗号化できます。

于 2008-09-09T00:37:32.720 に答える
0

ここで、統合セキュリティをオンにしてデータベースへの ODBC 接続を使用しているため、接続文字列にユーザー名/パスワードの値を書きたくない/書きたくないことを認めます (これは私にとって正しい選択です)。

この場合、幸いなことに、データに接続するときに別のユーザーを「シミュレート」する方法はありません。そのようなものを作ることができれば、統合されたセキュリティの大きな破綻になることを認めてください!

以前の投稿で、ユーザーが使用するクライアント インターフェースに応じて、ユーザーがデータを更新できるようにするかどうかを指定する必要があることを理解しました。私によると、アイデアは、リンクされた「更新不可能な」ビューを各テーブルに作成することです。呼び出されたテーブルごとに、 ...)Table_Blablablaというビュー (= Access ではクエリ) を作成するとします。View_Table_Blablabla

Access を使用する場合は、更新可能なテーブルを開くか、読み取り専用ビューを開くかを実行時に決定できます。これは、たとえば実行時、form_Openイベントで、フォーム レコードソースをテーブルまたはビューに設定することで実行できます。

于 2008-09-16T15:13:31.293 に答える
0

私がやりたかったこと (実験したばかりです) は、テーブルごとにこのようにデータベースへのリンクを更新することでした (注: この実験では、ODCB 接続を SQL Server 認証に切り替え、アカウントをSQL サーバーも同様です:読み取り専用- 更新できません。読み取り書き込み- テーブルに対する完全な権限があります)。

myTable.Connect = _
                "ODBC;" & _
                "DATABASE=" & "MyTestDB" & ";" & _
                "UID=readonly;" & _
                "PWD=readonly_password;" & _
                "DSN=" & "MyTestDB" & ";"
myTable.RefreshLink

これにより、彼らは編集できなくなりますが、後で読み取り書き込みを機能させることができません

myTable.Connect = _
                "ODBC;" & _
                "DATABASE=" & "MyTestDB" & ";" & _
                "UID=readwrite;" & _
                "PWD=readwrite_password;" & _
                "DSN=" & "MyTestDB" & ";"
myTable.RefreshLink

最初に接続した許可が永続的に固執するようです。読み取り書き込みを開始してから読み取り専用にすると、テーブルには読み取り書き込み権限が残ります

于 2008-09-17T16:31:23.920 に答える