Microsoft Access 掲示板

INSERT INTO の実行時エラー

12 コメント
views

求人管理簿の整理番号と、事業所データの事業所番号のデータ型はともに短いテキストで、両方とも主キーに設定してあります。
登録済みのデータという事はありません。
登録した事業所番号というフィールド名に問題があるのかと思い、削除して手入力し直してあります。
使用しているのは、office2021です。

    yname = Environ("UserProfile") 'ユーザー名を取得
    strFileName = "管理元帳.accdb" 'データベースのファイル名
    Set adoCn = CreateObject("ADODB.Connection") 'ADODBコネクションオブジェクトを作成
    adoCn.Open "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & yname & "\Desktop\提出分\" & strFileName & ";" 'Accessファイルに接続
    'Set adoRs = CreateObject("ADODB.Recordset") 'ADOレコードセットオブジェクトを作成

    strSQL = "INSERT INTO 求人管理簿([整理番号]) VALUES('test')"
    adoCn.Execute strSQL 'SQLを実行して対象を追加 →成功

    strSQL = "INSERT INTO 事業所データ([事業所番号]) VALUES('test2')"
    adoCn.Execute strSQL 'SQLを実行して対象を追加 →insert into 実行時エラー-2147467259(80004005) 引数が無効です

どう考えても、コードに問題は無いので、accessファイルが壊れたのかと思い
バックアップのファイルで試してみましたが結果は変わりません。

実行時エラー-2147467259(80004005)を調べてみたところ、
次のような記事がありました。

Microsoft Update により、Jet / ACE Engine のセキュリティ設定が強化されたことが原因でした。
具体的には、
外部(Remote)データベース・ファイルを参照するクエリを
デフォルトでブロックする仕様に変更
されたようです。

求人管理簿には登録できるので、違うような気がしていますが、
これが原因なのでしょうか?

対応策が分からない状態なので、よろしくお願い致します。

sql
作成: 2026/01/23 (金) 11:52:49
通報 ...
1
名前なし 2026/01/23 (金) 12:08:13 7f9f4@0e907

漢字の諸々をアルファベットに変更してもエラーになるかしら?

2
hiroton 2026/01/23 (金) 14:14:44 2ddb8@f966d

「insert into 引数が無効です」でググってみるとテーブルが壊れているんじゃないか?的な対応策があるようです

3

バックアップのACCESSファイルでも、エラーが出るのでテーブルが壊れたの原因とは思えないのですが、
コードに間違えは無いので、問題はACCESSですよね。
このテーブルはフィールドが238ありまして限界に近いのですが、
こういう事も、エラーが起きる原因になりうるのでしょうか?

実は、当初はEXCELだけで処理していたのですが、
シート数やデータが多くなると不具合が頻発するようになってSQL + ACCESSに移行しましたが、
ACCESSでもフィールド数が増えると、原因不明のエラーが増えているような気がします。
フィールド名の合計バイト数みたいなものもあったような気がします。
フィールド数が多いとここに抵触する可能性も出てきますが、
そうであればオーバーした時点で、フィールドが登録できなくなるはずですし。

どうも、200超えたあたりから動作が怪しくなる気がしますが、こんなことがあるのでしょうか?

4

追伸ですが、
手動でデータを入力してみたところ、1回目は引数が無効ですで入力できず2回目には登録ができる状態が、2回続けて起こりました。
やはり、フィールド名が増えてACCESSがキャパオーバーになっていることが原因のエラーなのでしょうか?

5

仕方ないので、XMLファイルでエクスポート→テーブル削除→インポートで、テーブルを入れ替えました。
今度は、
strSQL = "INSERT INTO 事業所データ([事業所番号]) VALUES('てすと')"
    adoCn.Execute strSQL
「事業所名フィールドに値を入力してください」(主キーは事業所番号に設定されています)で、エラー
試しに
strSQL = "INSERT INTO 事業所データ([事業所名]) VALUES('てすと')"
「事業所番号フィールドに値を入力してください」(主キーは事業所番号に設定されているので当然ですが)で、エラー

いったい、なぜこんなエラーが発生するのでしょうか?

6

事業所データテーブルのフィールドを190にまで減らして試してみましたが、同じエラー。
テーブル削除してから、手動で新規作成事業所番号のフィールドを作ったところ、処理はできました。
しかし、XMLファイルのエクスポート→インポートで、テーブルを入れ替えられないとなると、
エラーが起きた時に、データが取り出せなかった場合は、致命的な問題となってしまいます。
取り出せたとしても、フィールドを手動で作り直していたのでは、お話になりません。

そもそも、バックアップしてあったファイルも同時に書き込みできなくなったのでは、バックアップに意味がありません。

正しい対応方法をご存じの方がいらっしゃいましたら、ご指導願います。

7
名前なし 2026/01/23 (金) 17:23:39 7f9f4@0e907

事業所データテーブルのフィールドを190にまで減らして

 190まで減らしても多い。その数字が明らかに杜撰な設計とバレバレだから正規化やり直しましょうね。

8

strSQL = "INSERT INTO 事業所データ([事業所番号]) VALUES('test2')"
adoCn.Execute strSQL 'SQLを実行して対象を追加

実行時エラー-2147467259(80004005) 引数が無効です

手動でデータを入力してみたところ、1回目は引数が無効ですで入力できず
2回目には登録ができる状態が、2回続けて起こりました。

状況的には、既に行われた「XMLファイルのエクスポート→インポート」が最も有効な解決方法であると思われますが。

このテーブルはフィールドが238ありまして限界に近いのですが、

どうも、200超えたあたりから動作が怪しくなる気がしますが、こんなことがあるのでしょうか?

  • Access において、1 つのテーブルに定義できるフィールドの数は 255 個までである。

  • 1 つのテーブルにおいて、フィールドの追加/変更/削除を繰り返しているうちに、「実際に画面上で確認できるテーブルのフィールド数よりも多いフィールド数分の設定情報が保持されている」と認識される状態となることがある。

  • この「フィールド数のずれ」が含まれているテーブルに対してレコードを追加しようとすると、Access データベースエンジンが正常にデータを処理することが出来ず、件のエラーが発生する。

上記の「設定情報」を Access のユーザーインターフェース上で閲覧、編集することは出来ませんので、前述の方法によってそのテーブルをまるごと作り直すことでしか修正できません。

参考: access 実行時に、「引数が無効です」のエラー

いずれにせよ、この現象の性質上、フィールドの数を上限に近いほど増やしたり、1 つのテーブルのデザインの変更(フィールドの追加/削除からの上書き保存)を頻繁に繰り返すことはあまり推奨されません。

[事業所番号]と[事業所名]の他にどのようなフィールドが定義されているのか不明ですが、可能であればテーブル構成の再設計や正規化を検討されることをお奨めします。

strSQL = "INSERT INTO 事業所データ([事業所番号]) VALUES('てすと')"
adoCn.Execute strSQL

「事業所名フィールドに値を入力してください」(主キーは事業所番号に設定されています)で、エラー

テーブル[事業所データ]のフィールド[事業所名]の[値要求]プロパティはどのように設定されているのでしょうか。

9

フィールド名が限界に近づいていたのが原因でした。
とりあえず、テーブルを分割して凌ぎましたが、
どうしようもなくなったらMySQL当たりに変更するしかなさそうです。

ただ、AIで他の言語の書き換えは簡単にできるようになっているので、
いままで作ったものが、全く無駄になる事が無いのは救いです。
おそらく、AIに命令しただけでは、同じ処理ができるシステムを作ってくれないと思います。

当面の対応策としては、
[ファイル]タブ > [オプション] > [現在のデータベース] を選択し、「閉じるときに最適化する」にチェックを入れて最適化を試してみます。

10
名前なし 2026/01/23 (金) 18:49:54 7f9f4@0e907

どうしようもなくなったらMySQL当たりに変更するしかなさそうです。
 どこに変更しても上限はあるんですよ。根本的に見直しましょう。

11

JOINを使用すればテーブルを分けても、一度でデータを取り出せるケースは増えます。
しかし、フィールド数が少ないと、複数回SELECTする事は避けられないですよね。
複数回SELECTしても、配列に追加すれば済む話なので大したロスにはなりませんが、
今度は、配列を大きくし過ぎると止まるという制約が出てきます。

配列を使わないでシートに書き出していたら、この状態に至る以前に処理できなくなってるはずです。
必要事項には回答しないと許可が下りないので、項目を減らすわけには行きません。

難しくて、色々費用も掛かってくるであろうMy SQLは使いたくはないので、できるだけしがみつきますが、、、
「そろそろ、お前もっと金使えよ」という、IT君からの忠告げなんでしょうね。

12
sk 2026/01/26 (月) 18:58:54 修正 97383@c8a24 >> 11

JOINを使用すればテーブルを分けても、一度でデータを取り出せるケースは増えます。
しかし、フィールド数が少ないと、複数回SELECTする事は避けられないですよね。

「どのような構造を持ったテーブルを参照し、どのような条件に該当するレコードを抽出し、どのような演算、変換処理を行い、その実行結果を、どこに、どのようなレイアウトで出力しようとしているのか」によるとしか。

現時点では具体的にそれが示されていないので何とも答えようがありませんが、JOIN も SELECT も「する必要があればそうする」だけのことでしょう。

今度は、配列を大きくし過ぎると止まるという制約が出てきます。

配列を使わないでシートに書き出していたら、この状態に至る以前に処理できなくなってるはずです。

同上。
唐突に配列やシート書き出しの話をされましても、その辺りの詳しい事情や背景が一切不明であるため、答えようがありません。

例えば「参照元のテーブルに膨大な件数のレコードが格納されていて、その全てのレコードの全てのフィールドを取得しようとしている」といった場合、レコードの件数やフィールドの数、格納されているデータの大きさに比例してアウトプットに時間がかかってしまうのは当然の結果と言えます。
その上で「出来るだけ実行時間を短縮できるようにするにはどうすればよいか」という問題は全く別の話です。

必要事項には回答しないと許可が下りないので、項目を減らすわけには行きません。

「必要事項には回答しないと許可が下りない」がどういうことなのかが不明瞭ですが、その項目が本当に必要なものなのであれば、無理に減らす必要はありません。
ただ「リレーショナルデータベース上で管理するテーブルとして適切に構造化されているか」ということが問題なのです。

過去のスレッドから推定し得る限り、実際のフロントエンドは Access ではなく Excel であると思われますが、もし「元々 Excel で作っていた表(やたら列の多い非正規形テーブル)のレイアウトをそっくりそのまま Access のテーブルに落とし込んだ」ということであるなら、少なくともそのようなテーブル設計手法は Access に限らず、あらゆるリレーショナルデータベースシステムに適していません。

「どのような構造のテーブルをデータベース上に定義するか」
「どのようなインターフェースを用いてデータベース上のデータにアクセスするか」
「データベースに対してどのような問い合わせを行い、どのようなレイアウトの出力結果を得るか」
は、基本的に分けて考えるべきでしょう。