update.前回は、「データ10,00件Insert」という観点から「Query:sql」と「Table:importRows」比べました。今回は、「Table:importRows」を極めることを目的として、結論から言えば挫折したというお話です(笑)。※できているっちゃできているんですが前回のおさらい「Query:sql」と「Table:importRows」の違いQuery:sql⇒大量データ投入には向いてない(用途として成立しない)Table:importRows⇒少なくともGASからの動作は不安定Query:sqlAPIの仕様通り30件/分の制約があるため、件数が多いデータを挿入するのには不向き。Exceededこちらは原因も明確なので、10,000件のデータ投入には向いていない用途であると断言できます。Table:importRows15MB程度のデータ挿入でレスポンスが返ってこない。responseまた、繰り返し実行していると、内部エラーが発生する。again.こちらは詳細な発生原因は掴めていません。事実として起こりましたとしか言いようがないのが実態です。今回やること前回の実験では、500字×10,000件のデータ挿入でレスポンスが返って来なくなり、250字×10,000件ではレスポンスが返って来ました。今回の実験では、500字×10,000件のデータ挿入が問題なく行えるようにします。again」してやんよ300件ずつデータを挿入するようにして、レスポンスが返って来ない事態を回避するコードを書いてみた前回のコードを修正しています。tmp;};例によって生成する文字列は「下野由貴💛」の繰り返し。Endうむ!狙い通り!・・・どうみても異常系のログですが、僕としてはこれで良いんだ・・・良いんだよね?(弱気)良いわけがない!ところが、何度か実行してみると、非常に不安定です。いうか意味わかんないし(逆ギレ)。Exceededというエラーが頻発します。APIのQuotaちなみに他のテーブルを作成してそこにデータを挿入しようとしても発生します。異常終了これが最大の謎。日単位のリクエスト数でQuotaを定めているのであれば、ものすごい矛盾。Errorにしても、レスポンスが返って来ない件にしても、見えない敵と戦ってる感ハンパないっす結論ぶっちゃけ、ゴリゴリとプログラムするより、以下の手法が一番スマートなのかも知れません。Tablesに変換することが...できるのかは存じ上げませんが、次回のテーマはそれで。upLoginユーザーは見つかりませんでした。