I'm automating folder-creation for both projets and customers. The customer-folder has ~400 sub-folders and throws the same error. Exception: a servererror occured. wait and try again later (translated)
function test () {
DriveApp.getFolderById("28letterFolderIdxxxxxxxxxxxx")
}
The Apps Script is unable to access the main folder. It fails before doing anything fancy. I've tried multiple account; incl. owner.
I did a migrate a few folders (many hours prior) but are now starting to suspect that it's the size (360+ subfolder) that is the problem.
Drive-api works fine (get folder)
Same function (copy/paste) works in new script-file
Can script-files get corrupted? I rather not remake it, as it's a library, in use.
Solution: Script had a connected GCP-project where the Drive-scope hadn't been added. It also needed to be reinstalled.
Related
I am spending hours (literally) trying to find a way to change the DriveApp.Permission of my script (for web App).
Actually, its value is VIEW, not allowing me to create folders, files or edit them (read only).
The script is configured to run as "me", accessible for anyone.
I have checked the owner of the folder ( FOLDER.getOwner().getEmail(); ) and owner of the user/session ( Session.getActiveUser().getEmail() ).
Not surprisingly, they've returned the same value. I have read THIS, but without success in retrieving any useful information.
I think, the problem is around the DriverApp.Permission value.
I was brief as a possible, I think. Could someone help me?
To put it clear: the script, the driver, etc., all of them belongs to me ( \o/ ).
Example:
DriveApp.getRootFolder().getFoldersByName( "ExistingFolder" ).next().createFile( "No_authorized_it_will_not_be_created_and_will_trigger_a_exepction" , "Some TEXT" );
Google GET response (translated/approximated)
Exception: You don't have permission to call DriveApp.Folder.createFile. You need to have permissions :https://www.googleapis.com/auth/drive (line 135, file "InternalDriver")
With support of #Copper and suggestion of #TheMaster, my solution:
Add this JSON object to the manifest
"oauthScopes": ["https://www.googleapis.com/auth/documents", "https://www.googleapis.com/auth/drive"]
Create a new version of the project, and try it again.
I have removed the actual permission related to project before deploy a new version.
I'm not sure whether "https://www.googleapis.com/auth/documents" path is necessary for simple creation or edition of folders/files. The other path string is certainly needed.
I'm running Octave 4.0.1 on windows 7 and I'm having this weird issue.
I created a functioning script which is saved under C:/User/Documents/Octave. This script also reads some files in a subfolder of this same location.
The problem is : my script correctly runs TWICE then I have the error "no such file" saying the software did not find my script (the same one I just ran). The only "solution" I have is restarting the whole software but then it still goes nuts on the third run.
In addition to that, my coworker tried it on an ubuntu machine and it seemed to work fine. Do somebody see an explanation?
Thanks
Here is the script :
data = [];
figure();
for i=1:200
filename = strcat('C:/Users/Utilisateur/Documents/Octave/data/DAQ_data_decoded_', num2str(1800+i))
d=lvm_import(filename);
data=[data d.Segment1.data(:,2)];
end;
data=reshape(data,6600,1);
hist(data);
The function lvm_import is a function I found on the web to extract data from a Labview data file. (d.Segment1.data(:,2) is a 33x1 array)
And the error message :
>> daqDataHist
error: no such file, 'C:\Users\Utilisateur\Documents\Octave\daqDataHist.m'
So I still don't really know what was going on but by adding fclose all at the end of the script I got rid of any error and can run the file as many times as I want. It was probably something going wrong with opening and closing the .lvm files and it "jammed" at some point.
Thanks anyway :)
I have two bound scripts in a template I am replicating hundreds of times. The scripts are easy and small. They work fine in the initial template, but when I copy the file dozens/hundreds of times, it breaks 50% of the time and I get this error when I try to run them from the new file:
Server error occurred. Please try saving the project again. (line 0).
Saving the project again isn't working.
Why does my script break when I right click/make a copy of a Google Sheets, and how I can stop it?
I have taken 2 sample databases from online - one for a calendar and one for drag and drop functions - and pulled some code together for a result that is ALMOST functioning as I had hoped.
There is a function to build/refresh the calendar, which works perfectly.
The drag and drop functions work perfectly. (The item is updated in the table to reflect the new date.)
When I drag and drop, the calendar doesn't automatically refresh. If I click next month then last month (which call the refresh function with a new date), the changes are reflected as expected.
The problem is when I try to automatically call the refresh function after a drag/drop event. Access crashes every time I call for a refresh in the code after drag/drop, regardless of where I put the call.
The error says:
Microsoft visual C++ Runtime Library
Runtime Error!
Program: C:...
This application has requested the Runtime to terminate it in an
unusual way. Please contact the application's support team for more
information.
I have tried:
I thought it might be trying to refresh too fast, so I added a pause
function and had the program wait 10 seconds after dropping before
refreshing. Still crashed.
I did a compact and repair on the database.
I ran /decompile from the command-line on my accdb file.
I exported the relevant form, tables, query and module to a new accdb
file.
I have tried to re-register the libraries checked under references.
(RegSvr32 "Path to library file") The only one that succeeded was
vbe7.dll. The "MS access 14.0 object library", "OLE automation", and
"MS Office 14.0 Access Database Engine Object" don't contain a
DllRegisterServer method, so regsvr32 did not succeed with those. There are no other
references checked. Still crashes.
I have tried countless places to insert the call to refreshcalendar()
I have stepped through the code and verified the exact place that the
crash happens. It is commented in the code.
Here is a link to the database.
To reproduce the problem:
Open frmsubCalendar.
There are 2 entries in May 2014 that can be dropped to other days on the calendar. I can then click the prev/next month buttons on the form, and when May reloads, the change has been made. But if I go into mod_drag_drop under the sub dropdetect() and uncomment the lines noted in the comments, the refresh will crash access at the end of the dropdetect() sub.
I cannot figure out how to make the calendar refresh automatically after a drag/drop event without access crapping the bed.
I realize this is a bit outdated, but I had a similar issue and didn't see this one being answered, I figured I'd add this answer for posterity. :) I discovered it was caused by a reference to a function by the form name. I had the following call in a module:
lContractCt = Form_Census.lContractCt_f(bIsMembers)
Where lContract is a Long, there is a form named Census and a public function in that form called lContractCt_f.
I moved the function to a module (so the Form_Census reference wasn't necessary any more). And changed the call to:
lContractCt = lContractCt_f(bIsMembers)
This fixed the error. So, I would check if you have any public function references going from a module to a form and move those public functions into a module. I also saw a similar thread with a different form reference, via Forms![Census], for example.
chrome.fileSystem.isRestorable is a new part of the chrome.fileSystem API and it saif if a file can be restored with its entry or not. I've made many tests but something is wrong, when I tried to do :
chrome.storage.local.get(
["recentFileId1"],
function(recent) {
chrome.fileSystem.isRestorable(
recent["recentFileId1"],
function (isRestorable){
console.log(isRestorable);
});
});
It returns me true, even if the file has been deleted of my computer. recentFileId1 seems like a real id (many numbers and the path at the end, for example FD158F2A41037D17440C025C1CA5FE08:question.txt) and the file's restoration works if the file is still on my computer. When I tried to restore the file with an id of a deleted file it just returns nothing, no error.
So I want to know : did I use this feature wrong or something? It can work if I try to restore and see what is restored (if it returns nothing the file has been deleted), but I don't want to use a hack if the API is available.
Thanks.
This function is currently only available in the dev channel of Chrome, and should be released to stable in version 31.
What you're describing sounds like a bug, please file it at http://crbug.com. We should always return true or false. What the correct behavior in this case should be is not clear.
The intent of this function is to let an app know if it should provide UI to give the user access to previously opened files. If a file is restorable, it simply means the app still has permission to access the file.
We are reserving the right to limit when files are restorable. E.g. we might have an arbitrary upper limit to how many files can be restored, or the access might timeout after a few months, or we may give the user the option of not letting apps restore any files. isRestorable lets you know if access to a previously opened file is still available.
isRestorable is not intended to give information about how accessible the file still is. Local changes can impact this - e.g. the file might be deleted or the OS access permissions changed. It might still be there but be invisible to chrome and the app due to no read access to the containing folder.
Think about a recent documents menu. This could show files which were opened and since deleted. When the app restores a deleted app it would not work and would show an error to the user. At that point the user might go to their recycle bin or git checkout and replace the file.
Or the recent documents menu could just not show files which have been deleted.
Either way your app should not rely on isRestorable as an indication of whether a file entry can be regained and successfully used, you should handle restoreFile not restoring a file and giving an error, and handle access to the file having permission problems.