問題タブ [jet]

Web サーバーに格納されている JET データベースのいくつかのテーブルを操作する必要があります。

• 既存のインデックスを確認する
• テーブル クラスタ/主キーの変更
• 存在するテーブルを確認する
• テーブルの名前を変更する
• テーブルを追加
• ドロップ テーブル
• データを閲覧する
• 等

PlaneDisasterまたはAccessをローカル マシンにインストールするオプションがありません(持っていたとしても)。

一般的な Web ベースのクエリ ツールは既に作成しています。Web ベースのデータベース メンテナンス GUI 全体を作成する必要はありません。誰かがすでにこれを行っているに違いありません。

このクエリを使用して特定のデータを取得しています: "select * from emp where emp_name LIKE 's%'";

emp_nam は文字フィールドですが、数値フィールドで同じ論理条件を使用するにはどうすればよいですか? 何かのようなもの：

"select * from emp where emp_id ????

ここで、emp_id は数値フィールドです。

ありがとう、

DAO 3.6 には、行レベルのロックがサポートされていないという問題がありました。詳細については、このナレッジ ベースの記事を参照してください。

アクセスチームのブログから学びました：

Office Access 2007 では、Access データベース エンジンの新機能をサポートするために、新しいオブジェクト、プロパティ、およびメソッドが DAO に追加されます。

Access2007 Visual Basic Editor のオブジェクト ブラウザでこのライブラリを見ると、新しい化身は ACEDAO と呼ばれます。MSDN のホットフィックスで acedao.dll に関する言及を見つけることができますが、他には何もありません。

ACEDAO のエンド ユーザー ドキュメントがどこにあるか知っている人はいますか?

ACEDAO が行レベルのロックをサポートしているかどうかを確認するにはどうすればよいですか?

現在、SQLServerといくつかのAccessDBファイル間でデータをインポート/エクスポートおよびアクセスする動的SSISパッケージを作成しています。（技術的になりたい場合はファイルをジェットします。）

とにかく、私のSSISパッケージにAccessファイルへの接続文字列がハードコードされている限り、テスト中はすべてが成功します。これは素晴らしく、うまく機能します。私はこれに満足しています。

この問題は、Access DBファイル（データが配置される宛先ファイル）への動的接続文字列を使用するようにVB.NETアプリケーションを変更したときに始まります。AccessDBファイルを「埋め込みリソース」としてアプリケーションに保存しています。

アクセス先ファイルの作成に使用するコードは次のとおりです。

これは正常に機能し、パスを指定する場所にアクセスDBファイルという正しい結果を生成します。これは、SSISパッケージにハードコードされた接続文字列がある場合にうまく機能します。

接続文字列を動的に変更し、同じ正確なテストを再実行すると、次のエラーが発生します。

「レコードを読み取ることができません。「MSysAccessObjects」に対する読み取り権限がありません。」

SSISパッケージの接続文字列の正規表現は次のようになります。

ローカルハードドライブ上のこのファイルに移動して開こうとすると、回復不能な状態にあることを確認し、修復するように求められますが、正常に実行されることはありません。

1. ファイルの作成に関して何か見落としていませんか？（IO？）
2. 組み込みリソースに関する何かを見落としていますか？（彼らは私にはかなり簡単に見えますが、おそらく私は何か明白なものを見落としていますか？）
3. ファイルの状態が壊れていませんか？VS.NET IDEで、MSAccessを使用してローカルで開くことができます。
4. このAccessファイルを再作成する価値はありますか？修復を回避するためにスキーマを新しいファイルにコピーできることを読みましたか？これはすごい危険に聞こえます!!

もともと、Access DBファイルのユーザーロールとそれを使おうとしているSSISに関して、これはパーミッションエラーだと思っていました。しかし、それだけではないと思います。ユーザーはAdminに設定されており、（理論的には）機能するはずです。

私はこれをハック/修正すると思います。現在、埋め込みリソースを使用しないようにしています。FileIO呼び出しを使用して、ファイルを目的のフォルダーに明示的に移動し、そこからデータを入力します。埋め込みリソースのdbファイルが機能しない理由を誰かが知っていますが、埋め込みリソースから作成されていない場合、同じファイルは機能しますか？リソースからファイルを作成するときに完了していないものはありますか？

フィードバックや提案は大歓迎です。ご不明な点も大歓迎です。ありがとうございました。

****更新/2009年7月18日：**

[CreateDestinationFile]ルーチンを変更して、埋め込みリソースを使用する代わりに、ファイル/IOの直接コピーを実行しました。

そのためのコードは次のとおりです。

ファイルはプロジェクトから正しくコピーされていますが、次のエラーが発生します。

"OLE DBエラーが発生しました。エラーコード：0x80040E09。OLEDBレコードが使用可能です。ソース：" MicrosoftJETデータベースエンジン"Hresult：0x80040E09説明："レコードを読み取ることができません。'TABLE_XXXXX'の読み取り権限はありません。」

これにより、SSISにはローカルのMSAccessDBを宛先ファイルとして使用するための適切なアクセス許可がないと思われます。

SSISパッケージに接続文字列をハードコーディングすると同じファイルが機能するため、これは私には奇妙です。ここで何が起こっているのですか？

接続文字列式でわかるように、ユーザーとして[Admin]があります。だからこれはうまくいくはずですよね？また、この問題のもう1つの考えられる原因は、これがAccess2003で作成されたレガシーMSAccess DBであり、ボックスでAccess2007を使用しているという事実です。ヘルプ？

非常に奇妙な（そして不安定な）動作をするかなり大きなAccess DBを継承しました。つまり、データベースへの更新の一部が失われます。これを回避するために何ができるでしょうか？より良いトランザクション制御を提供するためのAccessの設定はありますか？

詳細は次のとおりです。

• 書き込みアクセス権を持つアクセスユーザーが1人います（非常に限られた数のユーザーによって共有されています。現在、他のユーザーは休暇中なので、私だけです）。
• 読み取りアクセスしか持たない多くの人が使用する別のアクセスユーザーがいます。
• データへのいくつかの変更は、書き込みユーザーによって行われます。
• テーブルやアプリケーションを離れて再入力した後、変更は「コミット」されたようです。
• しばらくすると（通常は一晩）、変更が失われ、データが古い値に戻ります。

この動作の原因は何ですか？

私たちの理論では、これはAccess内の奇妙なトランザクション制御によって引き起こされます。読み取り専用ユーザーは、クエリまたはフォーム内で使用されるデータに対して、ある種の「排他的ロック」を取得します。ユーザーがそのクエリ/フォームを離れると、Accessはこれがまだデータベースにあることを確認します。その間に書き込みユーザーがデータを変更した場合、読み取り専用ユーザーがクエリ/フォームを離れると、これらの変更は元に戻され、更新が失われます。これは意味がありますか？これはMS-Accessの既知の問題ですか？

また、この問題を回避する方法にも関心があります。これはAccessに固有のものであり、トランザクション制御が優れた「実際の」データベースに切り替えることによってのみ回避できますか？（技術的な観点からは、それは素晴らしいことですが、もちろん、プロジェクトのこの時点では避けたい緊急の作業です。）

ご入力いただきありがとうございます。必要な追加情報がある場合はお知らせください。

私のソフトウェアを使用しているクライアントの 1 つで行き止まりの状況に陥っています。販売された約 40 個の製品 (VB.NET 2005 を使用して .NET 2.0 でプログラムされたアプリケーション) のうち、約 2 個が応答しなくなり、デュアル コア CPU の 1 つのコアが 100% でスタックします (プログラムは 1 つのコアのみを使用します)。

最も論理的な推測は、この動作の原因となる無限ループですが、非常に多くのループを含む数千行のコードです。私が入手した情報は以上です。さて、この問題のデバッグにどのようにアプローチすることをお勧めしますか?

編集: 基本的に、ソフトウェアは、PC などの他のデバイスを使用して消費されたクレジットの量を計算する責任があります。これは Cyber​​cafe 管理プログラムであり、断続的に失敗します。つまり、失敗するとクレジットが差し引かれます。データベースのバックアップを作成する時期かどうかを確認するなど、他のこともバックグラウンドで実行します。

編集：解決しました。それは最もありそうもない問題でした。私が DBMS として使用した Access データベース エンジンは、実際には問題のあるアプリケーションの一部です。テーブルの 1 つで行 - JUST ONE FRIGGIN ROW - を操作するのは困難です。それを削除したり、他のテーブルのその行に関連するレコードを追加したりすることはできません。MS Access 2007 でさえ、その行を操作しようとすると CPU が 100% まで上昇します!

簡単な「圧縮して修復」コマンドですべてが修正されました。アプリケーションが起動するたびにそのコマンドを発行すると思います。そうすることで、これが再び起こるのを防ぐことができます。

WinDbg のおかげで、問題の場所を見つけることができました。リアルタイムセーバーなので、使い方を学ぶことをお勧めします。

MS Accessデータベースエンジンは、2GBの最大ファイルサイズを許可するように「調整」されていることがわかっています（または、内部的に配線されて、4KBデータページの2の累乗未満に制限されている可能性があります）。しかし、これは実際にはどういう意味ですか？

これを測定するために、MSAccessデータベースエンジンテーブルに挿入できる行の最大数を教えてください。

テーブルの定義を満たすには、すべての行が一意である必要があるため、一意の制約（PRIMARY KEY、、、、データマクロなど）が必要です。UNIQUECHECK

編集：私は理論的な限界があることを理解していますが、私が興味を持っているのは実際的な（そして必ずしも実用的ではない）、現実の限界です。

この構造を置き換える必要があります。

.mdb がサーバー ディレクトリにある別のもの。私は試した：

しかし、うまくいきませんでした。私はVB6を使用しています。何か案は？