MongoDB Cloud > Cluster > Collections > Not loading documents
(when I fill the form on web page it needs to be saved on database ryt? Saving but not getting to load or I can't See my collections)
But Applications works fine.
Expecting right solutions enter image description hereenter image description here
This happened to me tonight, same situation, app worked fine etc. I was able to get past this error by clicking on another collection in Atlas and then clicking back on to the collection that was giving me the error originally.
Also try restarting your browser, or even your computer if none of the above works.
Related
I have a WOPI host running in a Blazor server application with all of the .wopitest tests passing for the desired functionality (others skipped).
When I upload a word document, I am able to view the document with no issues. I am also able to edit the document, however when I try and edit the document a second time, I get an error.
The error doesn't appear to be handled and seems to originate in the Office online javascript file.
Error on attempting second edit
Following the error, I am still able to open the document for viewing. It is the same behaviour if I use the 'Editing' button in the Office Online page or directly navigate to the editing page using an edit action url.
Supplementary information:
Using ngrok to debug locally
.NET 6
Using SQLite database for holding file information (including path to file)
Using local folders for storing file contents (e.g. 'data' folder containing all files)
Similar issues with .xslx files beign corrupted upon editing and requiring a 'repair' when opened with Excel. This repair removes cells containing text and indicates that it removes the theme.
Viewing a word document gives the following console errors View document error
The first editing of a word document gives the following console errors Edit document error
I was expecting to be able to repeatedly edit the document.
I tried opening the file in the Desktop version of Word and got the following error Desktop Word recover
Following a recover, the document appears to work as expected in Word (desktop) but still won't open for editing through WOPI.
Turns out it was the way the POST http request body was being saved.
Still not certain what was going wrong but somewhere along the way of writing the stream into a buffer and then saving that to a file corrupted the file.
I suspect the file stream was either truncating or adding a few bytes.
The interesting part being that Office Online was still able to view the file.
This indicates there is some tolerance for malformed files still being served.
I tried to build an app based on the Document based app template. I am trying to get it to open markdown files. I got it to create the files and show up in the share sheet when viewing the file in the Files app. However in the Document Browser in the app (UIDocumentBrowserViewController) it is greyed out and cannot be selected. I can't really find what this is due. How do I fix this?
I tried it a second time, still did not work. A few days later however, the second one started working, the first one is still broken.
I am converting a normal image/video Url into a blob Url ,after conversion i'm storing it in INDEXED DB of chrome browser. To run the assets(image/video) in offline mode I have made this conversion.
When i run my application for three days continuously without internet,the image/video is not coming. As i'm running my application(it is a chrome extension ) in chrome box I cant able to inspect and see the error.Is there any expiry time for blob Url.
I have seen for whether auto clear of data is happening in indexed db or not, but for chrome extensions the indexed db will not get clear unless the user deleted it manually.
Thanks in advance
Check out this module, it lets you set data in your indexedDB only for x mins. After which, data is cleared automatically.
I'm attempting to retrieve a database backup we've put into Cloud Storage. To make a long story short, the url is gs://servername/year/date/data.sql
It's a little more complicated than that, but for the sake of this question, it'll do.
Anyway, when I use the Storage Browser (Projects -> Storage -> Storage Browser), I can get into /server/2014/2014-09/04/ - but this is where things get weird.
The subfolders/directories phase in and out of existence, only for this date. I can go in and out of the bucket subfolder of 2014-09-04 all day, and it'll have different results every time. Sometimes the incremental data is there, sometimes only the schema data is there. Trying to download any file from the storage browser gives a big fat "Not Found" blank error page. No links, no http response codes. Just, "Not Found". All our older dated folders are fine.
If I use gsutil to attempt to retrieve the entire subfolder, it says:
CommandException: No URLs matched: gs://servername/2014/2014-09-04
The command I ran was:
gsutil.py mv gs://server/2014/2014-09-04 c:\dbrestore\
Yet there it is in the storage browser, clear as day. (There is only one ACL, so I know that's not the problem) To make sure I wasn't doing something funky, I have copied dates surrounding it ok, so 2014-09-03 and 2014-09-05 are both completely accessible from the storage browser, and gsutil.
I am out of ideas as to what could be wrong. Frankly, something about the bucket looks stuffed. Has anyone run into this problem before, and if so, what did you do to go about correcting it?
All of a sudden one of our sites has developed an issue with TinyMCE, specifically it seems, in relation to the advimage plugin.
When trying to browse the image folder via TinyMCE I get an alert with one of these errors:
In Chrome I get:
2can't process ajax,TypeError: Cannot read property 'responseText' of null
In Firefox I get:
2can't process ajax,Invalid XML structure
Nothing has changed on this site for a good few months.
We have upgraded to PHP 5.4 very recently, but I don't see why that would be related.
This could be an issue with overly large images in the plugin's upload directory.
On each request, the advimage plugin scans the upload directory (set in your config) and generates thumbnails of any images it finds in there, then sends a list of images off to the client in the form of JSON or XML. If an image is too large to process, (low server memory or something), then the process quits and doesn't return any JSON/XML, hence the seemingly unrelated error message.
Prune any images over 1MB from the uploads directory. You may need to flush the cached thumbs as well. To stop your users/admins from uploading huge images, set an upload limit in the plugins config.