Some of our reports suddenly produce the following error message when trying to open them (from https://datastudio.google.com/)
We're sorry! Data Studio isn't available at the moment. Please try again later.
We are getting this message for more than 24h now. Any idea what the reason might be, and how to regain access to the reports?
While I still don't know what the root cause was, it's very likely something outside our sphere of influence. Looks like someone on Google's side pushed the wrong button, as it affected more users than just us (see, e.g., here and here).
So to fix this, have a look at the Google support forums, and then sit back, relax, and hope that Google is quick to do their thing.
Related
That is the case as of last night. Does not work for CPU or GPU "compute type"
Basically, after pressing the "Start runtime" button, it says "Preparing project runtime..." for about ten minutes and then stops. It shows the following error, "There was a problem when starting the project runtime. This should be resolved shortly. Please try again later."
I have now tried it about five times over last night and this morning.
There is no way to even access the work that is saved there. The "project" will not boot up.
Basically it is a dud at this point.
Is anyone else experiencing similar issues? What does one do?
The issues/questions and answers that I have learned since (because I was asked to clarify):
(1) The environment on Sagemaker Studio Lab is supposed to be persistent. I.e., any time one starts it, the environment, files uploaded, etc. are where it was left last. However, I was not able to start the environment any longer. Before it locked out, it would start fine. Consequently, I was not able to get to my saved work in any way shape or form. I was wondering if anyone has had this issue
Answer: Thus far not too many people are approved for Sagemaker Studio Lab. So, I may have been the first or one of the first to encounter this issue. As of this writing there does not exist a way to access ones data if one cannot spin up a virtual machine that would have access to the data using their "Start runtime" button.
(2) It is not clear where one is supposed to report issues with Sagemaker Studio Lab. On one's home page in Studio Lab, it has a link to StackOverflow under "Get answers and help others". That is how I ended up here. Though, I should have included the following hashtag (#amazon-sagemaker pointing to https://stackoverflow.com/questions/tagged/amazon-sagemaker).
Answer: I eventually found where people are submitting bug reports. And I reported the issue there (see issue 56). https://github.com/aws/studio-lab-examples/issues
(3) It was not clear to me if I was to delete my account and request a new one if I would be put on a waitlist (which supposedly is presently long). I.e., this would be the manual factory reboot option where one still loses all of ones work, but, at least has an opportunity to start again with the environment.
Answer: Once one is approved, one does not go to the waitlist. Deleting my account, requesting a new one, and setting it up to the initial state took a couple of minutes for me. And yes, I lost all my work that was on there. So, back stuff up as it was your computer in the `80s. I.e., back up externally to that environment.
I signed up for ASMSL about 2 weeks ago. As of this evening (Feb 15) I'm able to log into my runtime without any trouble at all.
We have built a website based on the design of the Kigg project on CodePlex:
http://kigg.codeplex.com/releases/view/28200
Basically, the code uses the repository pattern, with a repository implementation based on Linq-To-Sql. Full source code can be found at the link above.
The site has been running for some time now and just about a year ago we started to get errors like:
There is already an open DataReader associated with this Command which must be closed first.
ExecuteNonQuery requires an open and available Connection. The connection's current state is closed.
These are the closest error examples I can find based on my memory. These errors started to occur when the site traffic started to pick up. After banging my head against the wall, I figured out assumed that the problem is inherit within Linq-To-Sql and how we are using the same connection to call multiple commands in a single web request.
Evenually, I discovered MARS (Multiple Active Result Sets) and added that to the data context's connection string and like magic, all of my errors went away.
Now, fast forward about 1 year and the site traffic has increased tremendously. Every week or so, I will get an error in SQL Server that reads:
A severe error occurred on the current command. The results, if any, should be discarded
Immediately after this error, I receive hundreds to thousands of InvalidCastException errors in the error logs. Basically, this error shows up for each and every call to the Linq-To-Sql data context. Only after I restart the web server do these errors clear up.
I read a post on the Micosoft Support site that descrived my problem (minus the InvalidCastException errors) and stating the solution is that if I'm going to use MARS that I should also use Asncronous Processing=True. I tried this, but it did not solve my problem either.
Not really sure where to go from here. Hopefully someone here has seen and solved this problem before.
I have the same issue. Once the errors start, I have to restart the IIS Application Pool to fix.
I have not been able to reproduce the bug in dev despite trying many different scenarios involving multi-threading, leaving connections open, etc etc.
One possible lead I do have is that amongst the errors in the server Event Log is an OutOfMemoryException for the Application Pool. Perhaps this is the underlying cause of the spurious SQL Datareader errors (a memory leak elsewhere). Although again I haven't been able to reproduce this in dev.
Obviously if you are using a 64 bit OS then this is probably not the cause in your case.
So after much refactoring and re-architecting, we figured out that problem all along is MARS (Multiple Active Result Sets) itself. Not sure why or what happens exactly but MARS somehow gets result sets mixed up and doesn't recover until the web app is restarted.
We removed MARS and the errors stopped.
If I remember correctly, we added MARS to solve the problem where a connection/command was already closed using LinqToSql and we tried to access an object graph that hadn't been loaded. Without MARS, we'd get an error. But when we added MARS, it seemed to not care about it. This is really a great example of us not really understanding what the heck we were doing and we learned some valuable (and expensive) lessons from this.
Hope this helps others who have experienced this.
Thanks to all how have contributed their comments and answers.
I understand you figured out the solution..
Following is not a direct solution to the problem; but it is good for others to take a look at
What does "A severe error occurred on the current command. The results, if any, should be discarded." SQL Azure error mean?
http://social.msdn.microsoft.com/Forums/en-US/bbe589f8-e0eb-402e-b374-dbc74a089afc/severe-error-in-current-command-during-datareaderread
While exporting a Solution from CRM, I dont get the prompt to save the exported solution.
I cleared Cookies and tried,
Upgraded to IE 9 also and tried,
I made sure that the Popup is not blocked, but these things didn't help.
This is the case with few other colleagues of mine also.\
Thanks
I usually get a popup right at the bottom of the window. Its not instant however, Crm has to generate the solution file, so if its particulary large it can take a minute or two. I would suggest clicking export, finish the dialog and then waiting 5 minutes to see if anything happens (it needs a loading icon really).
If that doesnt work, try the same again with a small solution (one entity).
I know it is too late but I am adding the solution here if someone faces the issue again.
The issue was due to URLScan. It was solved by removing URLScan from ISAPI filters for CRM web site.
We use custom settings in a SalesForce app. We access it like so:
MySettings__c settings = MySettings__c.getOrgDefaults();
This was working fine, but today the app completely crashed. By that I mean the page doesn't load at all, I just get a white screen telling me an internal error occurred. We traced it down to this line of code - when it is commented out the page loads as well as it can without those settings (but at least it loads).
Running that single line of code in the System Log (using the Execute functionality) also causes a report of Internal System Error. The only thing the system log reports is "FATAL_ERROR Internal Salesforce.com Error." The Apex code modal reports "Internal System Error: 1018505045-332 (-920440070)"
The setting has values for the organization - we've also tried deleting the settings and recreating them to no affect. So far SalesForce has been no help beyond telling us to ask on their website.
This is very frustrating as it was working fine on Friday and today it was broken before anyone touched anything.
What you have there is a platform error. Whenever you get those you should report them to SFDC support and they will be able to see further internal logging to sort it out.
Nothing anyone out here can do to help I am afraid.
Paul
try setting the apiVersion of the affected code back to version 21.0. We had the same issue and making this change has provided an effective workaround.
This was a bug in Salesforce's infrastructure, which has been reported resolved. If you're still seeing this error with API version 22.0, you should create a case with salesforce support.
I'm facing an extremely weird bug here and I'm not really sure If I'm following the right path to solving it or even how to solve it.
Here is the problem I'm facing: I start debugging a WPF application which uses log4net, NHibernate and LINQ to NHibernate, and when I try to get an Entity from the database my application and sometimes VS hang for a lot of time, and after a while an exception dialog opens showing a message containing the following information on a ContextSwitchDeadlock MDA:
The CLR has been unable to transition from COM context 0x34fc1a0 to COM context 0x34fc258 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this
I copied the code files to a new project and deleted the old project to see If I could make this message disappear, thinking it had something to do with my configuration. I started adding few things at a time to see what was causing it, and when I included log4net configuration code the bug appeared again. First I included it through AssemblyInfo and later trough code configuration on application startup, and absolutely nothing changed at all :(
So, here are my findings:
It only happens when I'm using log4net.
It happens when NHibernate loads an Entity from database (lazy loading).
I don't know what might be the source of this bug. It only happens when debugging in Visual Studio. I've tried following the steps on the "Enabling and Disabling MDAs" section of the following page: http://msdn.microsoft.com/en-us/library/d21c150d.aspx, but that doesn't work either, VS still hangs and it's memory usage increases.
When I run the program normally none of this happens, so I'm pretty sure this is not a deadlock situation, as this question suggests: contextswitchdeadlock (I've also tried the solutions posted there).
Because of that, I've decided to disable log4net and enable it again when deploying my app.
I'm posting this question to find out if somebody else has faced this bug or if somebody has some suggestions on how to solve it. Finally, it might help somebody else facing this very same problem.
When using the DebugAppender all the entities in the databases are loaded and all its data written to the debug output. That was causing the ContextSwitchDeadlock MDA since it tookmore than 60 seconds to run.
Disabling the DebugAppender solved my problem.
Thanks to Mauricio Scheffer for the tip.