アップロード更新最終更新日: 2021年7月22日

処理の詳細

アップロード更新機能は、1行目にヘッダ(項目名)が含まれていることが前提となります。ヘッダはダウンロード機能で出力されます。

更新

  • 列の並びを変更することができます。ヘッダ部を含めて、並びを変更してください。
  • 特定の列を削除すると、その列を更新の対象から除外することができます。(データベースの値がそのまま維持されます。データベースの値が null の場合も、null のままとなります。)
  • アップロードするデータに含まれる主キーが一致するデータが存在していれば更新となります。存在していなければ新規登録となります。
  • アップロードするデータが空白の場合、新規登録画面や更新画面で空欄として入力することと同様の扱いとなります。必須項目の場合はエラーとなります。非・必須項目の場合は null で上書きされます。
  • 新規登録時に、対象モデルの主キーに順序を適用していた場合、主キーを自動設定することができます。詳細は以下の説明をお読みください。

新規登録

対象データの主キーが順序を利用する設定の場合、データの主キー項目を "-1" にすることで順序が適用されます。(自動採番処理)

主キー項目に「-1」を指定

削除

データの削除を行うには、アップロードするファイルに「<Status>」という列を追加します。 図2では、主キーが 1007 のデータを削除するように指定しています。

※ 識別文字は大文字、小文字のいずれも利用できます。

<Status>列を追加する

注意

<Status>列は自動では付与されません。必要に応じて手動で付与してください。

<Status>列にはデータを新規登録・更新・削除のいずれかを識別するための文字(命令)を設定することができます。

識別文字 処理 内容
i 新規登録 新規にデータを登録します。
u 更新 データを更新します。なお、主キーに対応するデータがない場合はエラーとなります。
d 削除 データの削除を行います。
n なし 何も処理を行いません。
空文字 通常と同じ処理 主キーに対応するデータがある場合は更新、ない場合は新規登録を行います。

コミット単位

コミットは1行(1データ)単位で行われます。

※ あるデータで何らかのエラーが発生した場合、このデータは更新されませんが、その他で正常更新されたデータはすべてコミットされます。全体をロールバックする機能はありません。

エラーの扱い

アップロード更新の途中にエラーが発生した場合、エラーが発生した行はスキップされます。全体の処理は継続されるため、それ以降の行はアップロード更新されていきます。

※ 100件のアップロード更新で、50件目がエラーであり、それ以外の行はすべて成功となっている場合、99件はコミットされ、50件目となる1件だけがエラーとなります。

読み取り専用項目の扱い

読み取り専用項目はアップロード更新の対象から除外されます。

入力チェック

アップロード更新では、リポジトリで指定した入力チェックが適用されます。

データの形式エラー(必須チェックや、数値を入力すべきところに非数字を設定した等)が発見された場合、画面にエラーデータの行番号とエラーメッセージが表示されます。データは更新(登録)されません。エラーのないデータのみが更新(登録)されます。

親子モデル関係における、親モデルからみた子モデルの扱い

親モデルのスクリプトで子モデルを参照している場合、子モデルを操作する処理内容によってはパフォーマンスに影響があります。

※ 親モデルが複数の子モデルを参照するようなスクリプトがある場合、親モデルの件数 x 子モデルの件数分だけデータベースアクセスが発生します。これは負荷の高い処理になります。

親子モデル関係における、子モデルの単独アップロード

子モデルを新規登録する場合、親モデルの存在チェックは行いません。そのため、親が存在しない子のデータを作成することができます。

モデル参照項目の内容部に適用されるフィルタ

アップロード更新でも(画面入力と同様)フィルタが適用されます。 モデル参照項目の内容部文字列には、参照項目のフィルタ設定が用いられます。

※ 例えば「顧客名」が顧客モデルを参照している場合、顧客モデルの「顧客名」に設定されたフィルタが用いられます。

対応していない型

ルックアップ型項目の参照先がチェックボックスの場合には未対応です。(更新されません。)

処理件数の扱い

処理件数は「登録」「更新」「削除」「エラー」の行数の合計になります。

入力チェックエラーにおけるエラーメッセージ

例えばアップロード更新でエラーが発生し、そのメッセージが次の内容とします。

"2-4 行目 : 1 の項目に 1 を入力することはできません。"

これはヘッダ行込みの行数表示です。エラー処理結果ファイルをダウンロードした場合も同様に行数表示となっています。

この理由は、アップロードしたファイルの実際の行番号と、エラー行を一致させるためです。(どの行がエラーか、を把握しやすくするため、です。)

エラー時の動作

特定行のみエラーの場合

特定の行にエラーが含まれていた場合、当該行のみ処理がスキップされます。次の行へと処理を継続します。

致命的なエラーの場合

致命的なエラー(ファイルの破損、ダブルクォーテーションの整合性がとれていない)に遭遇した場合、その時点で処理は停止されます。このとき、エラー行の前までは更新されます。エラー行以降は処理がスキップされます。

独自に用意したファイルをアップロードする

Wagby のダウンロード機能で取得したものではない、オリジナルのCSVファイルもアップロード更新に用いることができます。次のルールを適用するようにしてください。

  • 先頭(1 行目)は日本語の項目名を記載します。項目名はダウンロード機能で取得する形式と同じものとします。異なる項目名を使用した場合は、正しく更新されません。
  • データ中に 「"」, 「'」, 「(改行)」のいずれかが含まれる場合、そのデータ全体を引用符 「"」で囲むようにしてください。これはCSVファイルの仕様です。
  • データ中に含まれる「"」は「""」へと置換してください。これはCSVファイルの仕様です。

ワンポイント

Excel が提供する「CSV形式で保存」機能を使うことで、上記で示したルールに基づく(引用符「"」を正しく考慮した)CSV ファイルを用意することができます。

注意

リポジトリの設定によってはヘッダ行の項目名とデータベースのカラム名が同一とならない場合があります。
このため独自にアップロード更新用ファイルを用意する場合は、一度ダウンロード機能を実行し、アップロード更新対象となる項目名が完全に合致するかどうかを確認するようにしてください。

複数のファイルをzip圧縮して送信する

複数の CSV 形式のファイルを 1 つの zip ファイルに圧縮し、これをアップロード更新することができます。次のルールが適用されます。

  • 同じモデルに関するデータを複数の CSV ファイルに分割して登録できます。
  • ファイル名のアルファベット順に処理されます。
  • zip ファイル内に処理可能なファイルが一つも含まれていない場合は、エラーメッセージを表示して終了します。
  • エラーがあった場合、エラーメッセージの先頭に処理対象ファイル名を記載します。これによって、どのファイルでエラーが生じたかがわかるようになっています。

ログオンセッションの数え方

アップロード更新は処理の最初に内部でログオン処理を行なっています。これにより、ライセンス制限上のログオン数を超えた場合は注意が必要です。

例えば1つのログオンアカウント(ユーザー)で同時に5モデルのアップロード更新を行った場合、ログオン数は6とカウントされます。

トラブルシューティング

特定のデータが処理できない

次の点をご確認ください。

  • データに不正な文字(特殊文字、外字など)が含まれていませんか。
  • データが「一意制約チェック」に違反していませんか。
  • CSV形式でダウンロードしたファイルをExcelで開き、その後、保存しましたか? Excel の仕様で、前詰めに "0" を含むデータは、その "0" が消えてしまいます。例えば、実際のデータが "000123" だった場合、このCSVファイルをExcelで開き、保存すると "123" となります。この値が主キーだった場合、該当データが見つからないという問題が生じます。

注意

これを防ぐために、Excel では「CSV取り込み」という機能があります。CSVファイルをダブルクリックするのではなく、ExcelのメニューからCSVファイルを読み込むようにすることでこの問題を回避できます。

特定の列が処理できない

  • 特定の列だけ正しく処理されない場合、アップロードするファイルの先頭行の「列名」と、設計情報に記載した「列名」が正しく一致しているかどうかを確認してください。列名が完全に一致しない場合、その列の処理は行われません。
  • 登録画面または更新画面のいずれかが読み込み専用となっている項目は、アップロード更新の対象外となります。

[事例] 新規登録が正しく処理されない

次のようなファイルをアップロードします。なお、処理時にデータは1件も登録されていなかったとします。

ID, 名前
1000, aaa
1002, bbb
1001, ccc

このとき、次のような動作となります。

  1. データは1件も登録されていない状態ですので、1行目は新規登録となります。ここで "1000" という値は使われず、順序から自動採番されます。Wagbyの内部ルールで、主キーは "1000" から開始されます。ここでは偶然にも同じ "1000" が発番され、1行目の登録は成功します。
  2. 2行目も新規登録となります。ここで "1002" という値は使われず、順序から "1001" が発番され、登録されます。この時点でのデータベースの内容は次のとおりです。
    1000,aaa
    1001,bbb
  3. 3行目はすでに "1001" というデータが登録済みのため、更新扱いとなります。よってデータベースの内容は次のように書き換えられます。
    1000,aaa
    1001,ccc

対策(1) : このような誤動作を防ぐため、順序を用いたモデルへの登録は主キー部分を "-1" と設定するとよいです。

対策(2) : アップロードするデータはあらかじめ主キーでソートしておくようにします。(例えばダウンロード機能でデータを取得する場合、主キーでソートさせたデータを使うといったルールを定めることで未然に回避できます。)

[事例] モデル参照項目の更新で、参照先の名称が異なっていた

例えば「会社」モデルを参照しているデータで、会社名に「山田商店」と記載していたが、実際の会社モデルにこのデータが存在しなかった場合、この項目そのものの更新が行われません。

[事例] モデル参照項目の更新で、無効なデータに更新しようとした

「選択肢モデル>選択肢を無効にする」設定で、あるデータを無効化(論理削除)していたとします。ここで、無効なデータに更新しようとした場合、更新エラーになります。

[事例] モデル参照(チェックボックス)型項目に対して必須入力チェックを指定している

すべてを選択していない状態でアップロード更新するとエラーとなります。一つ以上を選択してアップロード更新するとエラーになりません。

[事例] 異なるコードに同じ内容(データ)を設定した

このようなデータが存在した場合は、無視またはエラー扱いとなります。例えば「性別」モデルに次のようなデータを設定したとします。

コード
1
2
3!重複した内容

このとき、"女" から "男" へのアップロード更新はエラーになります。コード1と3のどちらを使えばいいか判断できないためです。

画面上には、次のようなエラーメッセージが表示されます。

項目 XXX に指定された値 YYY で問題が発生しました。同じコードに複数の値が設定されています。そのためどのコードを更新するか特定できません。