Task:
For each of our clients, we need to build eight spreadsheets with a minimum of two triggers each: 1) on Open and 2) Time based to refresh specific data from a larger spreadsheet. (This is a workaround for failing IMPORTRANGE functions.)
We currently have 100 clients, and are expanding to 200 shortly. Therefore, our current need is approximately 800 spreadsheets, and 1,600 triggers; projected to be 1,600 and 3,200 respectively very soon.
Problem
After creating the first 300 spreadsheets (approximately 600 triggers) we have received the following error:
Your Quota of Triggers has been exceeded. To Create more, you must delete some existing triggers.
Desired Solution:
We are collecting the eight spreadsheets on a private Google site for each client. Ideally we could invoke each spreadsheet script from the site, and eliminate time-based triggers. Tried creating a button to execute the script, but on the site, it is not interactive.
Questions:
Operating on Windows 7, error is in Chrome also tried Firefox, and got same error.
1)a Does anyone know of the limits on triggers, is it published somewhere?
1)b Is there a way to increase these limits?
2) Any ideas on another work around or solution?
Eric already answered your question (1). (No, and no)
Now to question (2), a possible workaround is to invert the scenario of your scripts, instead of each script fetch its data on the "larger spreadsheet", a single script on your master could distribute the data on all other spreadsheets. You could have some kind of "registration" of each spreadsheet, maybe place them in the same folder, or any other way that suit you.
By changing the approach to this one, you'll surely run into another limitation, which is the script total run time: 6 minutes. But this problem you can easily work around by splitting the task into minor chunks that you can work and resume on a every minute trigger.
There are limits to the number of triggers one user can have, but they aren't published and they can't be changed.
Related
I'm working on an addon that needs to update spreadsheets in user specified intervals (from once an hour to once a year) - is there a smart, proven way to handle that with automatic trigger check/installation and multiple users between multiple spreadsheets?
From what I understand the triggers are installed individually per user - can anyone reveal the mystery behind how the time-driven triggers for add-ons work in the following cases?
The check whether triggers are installed doesn't 'see' if it's been been installed by other users and it can't manipulate it (eg. delete someone else's trigger when no longer needed). Any ideas on how to cope with that? Having 50 users with installed hourly triggers is not ideal.
Multiple spreadsheets with the addon installed: will the trigger run the called function in all of them simultaneously or do they require individual triggers per sheet? Dry testing seems to indicate that the triggers need to be set up individually per sheet, though would be great if someone could confirm their experience from an add-on that's already online.
In order to control a potential chaos I'm considering adding a 'last updated' property to scheduled update instances and have the triggered function compare the time difference between that and current time, but then it's still going back to having that function run every hour multiplied by the amount of users.
will the trigger run the called function in all of them simultaneously or do they require individual triggers per sheet?
Installable triggers are installed per [sheet | document | form] per [user] (well, to be precise, per script project). Given the fact that they are isolated for each user, they are also triggered respective to each user (as opposed to simple triggers).
Installable onOpen | onEdit | onChange
There is a case, though, where this might not be as easy - see installable onOpen triggers section in official guide. Although the general case still holds - even if the other account will trigger it, the trigger will be run against creator's account, which includes quotas and everything user-related, so be extra careful with that.
Any ideas on how to cope with that?
Although [installable] triggers are not shared across users, some resources are shared between them, so you have at least two possible ways to deal with concurrent triggers firing:
Preferred way: LockService. It is specifically designed to avoid race conditions such as your case: just wait (or reschedule if the action might take more than 5 minutes) until the lock can be aqcuired (note that you need to use a script or document lock).
Fallback way: if you intend to let users concurrently interact with the UI, the lock will fail (by design). You had a right idea of using PropertiesService (I assume that this is what you meant by "adding a property"), but beware that reads / writes are subject to quotas.
I recently answered a similar question - it has a working and tested sample of emulating LockService behaviour with PropertiesService (but again, be careful with quotas).
Notes
You have to be aware of the problem with time-based triggers and account for that (also the referred answer contians a simpler to implement solution for checking the timestamp).
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 3 years ago.
Improve this question
using google apps script, I have written a big code that take high execution time whenever you increase the amount of sheets in the spreadsheet, i want to overcome the problem by dividing the custom function into 6 custom functions, each will run quickly on its own, but in order to do that, I will assign an onOpen() trigger through a menu on the UI that this specific user can only click and execute its related function.
my question is if I have 6 users per 6 functions, how many times a single user can open a sheet and use that menu daily?
i.e., user1 will have to use 5 spreadsheets daily, in each spreadsheet he will access 30-50 sheets.. that's a total of 250 sheets (max). by doing this, will he go over the triggers daily limit?
this will surely make my code run smoothly, but will consume many simple triggers per user.
Disclaimer: Not tested
Quotas in questionref:
Triggers: 20 per user per script
Total trigger run time: 90min/day(upto 6hr/day)
Inferences/Assumptions:
The Triggers refer to the number of triggers created and not the number of times each trigger is run. i.e., A user can open a spreadsheet as many times as he possibly can and still have the onOpen() trigger(1 trigger) execute, provided the user doesn't cross other quotas.
Simple onOpen() has a limit of 30 seconds. At a max runtime of 90 minutes/day and assuming a simple trigger runs for 30 seconds and simple triggers count towards 90minute quota, Users can open a spreadsheet upto 180 times and can still expect the onOpen() to run.
Manual menu clicks don't count towards total trigger runtime. So, I don't think it counts towards triggers run time or the number of triggers created(unless the script programmatically creates a trigger)
Workarounds:
Highly optimized scripts have, rarely a reason, to split up a script due to execution time. Make sure you've followed all the best practices. Related Questions:
Batch up operations
Avoid getValue() and setValue()
If that is still slow, You can offload work to Sheets API. You can use Advanced Google services or UrlFetch to directly access the API. The API does all the work, while your script simply makes the request to do something.
I am using Google Apps Script to create documents based on a template and some data stored in a spreadsheet. It was previously working well but recently (without having changed any code) I started getting the below error during a "google.script.run" call from a very simple HTML sidebar:
Execution failed: Memory limit exceeded
The error occurs during the copying process - it seems to occur at slightly different places each time the script is run.
I don't see any references to memory limits in the apps script quotas and a general Google search doesn't seem to find anything.
Can anyone shed some light on this and how to determine the limit/what is holding most of the memory/increase the limit if possible?
Check the methods that you're using to get the data ranges.
i.e. if you use sheet.getRange(A:X) it'll get all the rows in the sheet, even the empty ones (probably in the order of tens of thousands, or even hundreds of thousands). It's a better option to use the getDataRange method, which get the last column and last row with data.
Be noted with the Quotas for Google Services. Apps Script services impose daily quotas and hard limitations on some features. If you exceed a quota or limitation, your script will throw an exception and terminate execution.
I'm not sure if I have encountered with a bug or is just me not fully understanding how triggers work, probably the second one :D.
I have a google apps script that collects information through a series of requests to our CRM's API and puts it on a Google Docs Spreadsheet, the script takes a while to run, however, it runs successfully (I run it manually every morning, takes about 3 minutes). But when I try to automate that task, I get an error message saying my script exceeded its execution time limit.
I tried setting up my triggers manually, creating them within the script, breaking down my script reducing the number of API requests (taking less then a minute to execute) and execute it several times so I get the whole information. Every single time I get the same error message.
Am I missing something here? Any help will be much appreciated!
Edit: The mail I received has this error message: "Exceeded maximum execution time".
Edit2: I was able to fix this (party). I came across the answer for this question Exceeded maximum execution time in Google Apps Script and worked like a charm.
There are some limits to Google Apps Scripts that you must keep in mind: see Quotas.
It is possible that you are exceeding your total runtime for Triggers. There is also the shorter individual execution time limits on Triggers. I think I remember reading somewhere that Triggers have a lower total execution time limit per execution, but I can't remember where I saw it, and I can't find a source, even in Google's documentation.
This SO question is also similar...
I wouldn't say it's a bug, however as my own painfully experience, I can tell it's not the same running the script manually than through a time-driven trigger.
Sometimes it's just slower, but others it fails for timeout.
I don't know your specifics (there is no code available), but I would recommend you to use a retry exponential backoff function wrapping any critical call and also check for a timeout warning (let's say at 5 minutes) within the main loop.
So I got the error message in the subject on the 1 (one) script I had running yesterday and I am assuming I will get a similar message today.
I have improved the script (which has a trigger to run once per minute) so it functions more along the lines of how it is supposed to however the error message got me thinking as to what sort of functions or bits of programs might be asking for more service time than others.
For example, I have had to use multiple sleep calls in my google apps script to allow the data import to run and again for the worksheet changes/copy paste calls to process. Are all those sleep calls counting against me in terms of service time used?
I would ask on the community's behalf that this be left as an open ended question not specific to the sleep function. What sorts of parts of a script are demanding service time and which are not (if any).
Every call to a service (Spreadsheet, Calendar or whatever) takes more time than regular JavaScript operations.
For example, if you have to modify 10 cells in a Spreadsheet,
calling range.setValue() 10 times takes far more time than having all the data in an array and then updating the spreadsheet in one go using range.setValues().
If you can paste pieces of your code, the community will be able to offer more advice on how to improve your script.
The limit is on CPU time used in time based triggers, and I believe those sleep calls are counted against your limit. I'd encourage you to find ways to avoid the sleep calls, or schedule your script to run less often.