I have a client who use the built in feedback system to get his notes, but suddenly when I tries to go to the feedback I got the error as described in the image below.
I tried to delete cookies in the system and nothing happens, is there any solutions.
Regards
Related
I am unable to create a new Common Data Service Database in my Power Apps default environment. Please see the error text below.
It looks like you don't have permission to use the Common Data Service
in this environment. Switch to a different environment, or create your
own.
Which as I understand I should be able to create after the Microsoft Business Application October 2018 update as listed in the article available at following link.
https://community.dynamics.com/365/b/dynamicscitizendeveloper/archive/2018/10/17/demystifying-dynamics-365-and-powerapps-environments-part-1
Also when I try to create a Common Data Service app in my default environment, I encounter following error.
The data did not load correctly. Please try again.
The environment 'Default-57e1485d-1197-4afd-b792-5c423ab508d9' is not
linked to a new CDS 2.0 instance. The operation 'ListInstanceMetadata'
is forbidden for unlinked environments
Moreover I am unable to see the default environment on https://admin.powerapps.com/environments, I can only see the Sandbox environment there.
Any ideas what I am missing here?
Thank you.
Someone else faced a similar issue and I read in one of the threads about deleting the browser cache and trying it again or trying it in a different browser resolved the issue. Could you try these first level steps and check if you still have these issues?
Ref: https://powerusers.microsoft.com/t5/Common-Data-Service-for-Apps/Default-Environment-Error-on-CDS/m-p/233582#M1281
Also, for your permission error ref: https://powerusers.microsoft.com/t5/Common-Data-Service-for-Apps/Common-Data-Service-Business-Flows/td-p/142053
I have not validated these findings. But as these answers are from MS and PowerApps team, hope it helps!
So I have started the migration process from parse db to a mongolab db. The migration needed to be canceled at the verify stage. After pressing cancel, the migration tool is now stuck on the verify phase with no way to restart.
Has anyone else ran into this issue or have any ideas on how to restart the migration tool? Thanks ahead of time.
What I have attempted:
Removing and creating a new MongoLab DB
Multiple browsers
Logout/login
Parse Migration Tool Image
This issue seems to have been fixed on the parse side. But if it still happens, you have contact parse directly using the job id.
https://github.com/ParsePlatform/parse-server/issues/42
We discussed this here and basically in order to deal with migration
issues, we need you to individually report a bug through
parse.com/help. This allows each of you to get individual support,
from a team who can escalate issues, and for us to be able to ask up
front for specific information which will help us handle your issue.
We're exposing the 'job id' for the migration in the UI, and that is
something you should provide if you're having a problem.
Going to close this issue. For problems involving migration, or any
issues not specific to parse-server, please visit
https://parse.com/help and find the bug icon / "Something wrong?"
section to start the bug reporting flow.
I have come across an odd error I have never encountered before in the audit logs:
As you can see there are no details displayed but rather just an image
When I click on a specific line I only get this:
I haven't the faintest idea of where to start looking
I am a system administrator in the system so I don't think it's a permissions issue.
I can also confirm that there are real values in the system where the audit logs display that image instead of a value.
It seems to be a widespread issue across almost every entity in the system too.
EDIT:
I have looked in the audit management logs and found this:
I guess this indicates that no logs have been deleted?
This occurs when auditing was switched off and on again. From that moment the system cannot guarantee that the audit trail shown is complete and therefore it displays a torn page symbol.
I have a CodeIgniter setup that has been running fine for the past 2 months and recently I keep getting:
CodeIgniter error- unable to connect to database using the provided settings
I've recently added a new domain that has a landing page for the database login (zPanel), but I don't see how that could have caused a problem--maybe the page keeps getting directory attacked or something, but I'm not sure.
Is there a way to check if this is the problem through logs? I'm at dead ends with this problem, as when I restart the server (DigitalOcean) it works fine again.
Really not sure. If anyone else has had a similar problem, I'd love to hear your solution.
Thanks.
I think your mysql is going down so Codeigniter can't connect to your database settings.
Please login to SSH and check processes by "TOP" comment. See what is using resources ram or cpu.
And check your mysql conf settings, be sure that everything written if its empty it will cause alot of problems.
Some example :
http://www.maxwhale.com/how-to-optimize-mysql-for-1gb-memory-vps/
I'm setting up a new website and the site uses asp.net membership. This was working fine but today when I try and log in or do anything such as add a new user/role in the asp.net configuration wizard I get:
Warning: Fatal error 9001 occurred at Jul 30 2012 7:52PM. Note the error and time, and contact your system administrator.
Searching online, it seems to suggest that the logs are full, but I'm advised by the website host that there is ample free space, so I dont really know what to try next.
Has anyone come accross this before and if so, how did you manage to resolve it?
Thanks
I have had this problem recently too and after mountains of research it appears to be common when a database is set to AUTO CLOSE. I set all the databases to AUTO CLOSE = FALSE. This started with one database then went over to two and the next it was on all of them. I simply restarted the SQL Server Instance Service instead of restoring databases. Another way to fix the symptom is to take the problematic database offline and bring it back online again.
As it turns out this was a database issue. I couldn't even create a new table or drop a table and ultimately had to get the database restored, which solved everything.