Can someone help me to identify the root cause and how to resolve this issue?
The object you are trying to update was 'WorksheetData:pc:XXXX', and it was changed by System at 03/14/2022 7:04 PM. Please cancel and retry your change.
When I checked it in the guidewire display.properties
The question is very vague and not much context is available.
But in general, this error means that the current object being updated is already being updated by another person/process.
Is this a webservice, UI action or any other specific functionality?
There can be several ways to fix this with the most common one being a retry counter.
Catch the exception and retry the operation again. Depending on where you are facing this issue, different solutions can be applicable.
The error is caused because the bundle has been already committed and the period is now locked and users or system cannot change the locked branch. Usually to avoid these errors use touch() property of the bundle instance as it increase the bundle version property.
Related
My goal is to make sure I have a stable process for handling extension updates. I'm about to release a new extension and have noticed that the background service worker goes stale. Here are the details:
My method of testing this lifecycle is by generating a new build artifact and drag-n-dropping it into the page chrome://extensions. I hope this is the way to test this lifecycle. But if not, I would be happy to hear the alternative.
Once I drag and drop, I open the background console to check for the correct version, but seems it lags behind. The only way to remedy this issue is by removing the extension completely and loading it back, this gives me the impression a regular user would experience the same issue.
The screenshot below describes the situation:
version 0.3.33 is currently installed
drag and drop new build version 0.3.34
after successful drag and drop, notice version is lagging with version 0.3.31
But the chrome.runtime.onInstall release accurately outputs the previous version
Furthermore, I took a look at the unpacked extension directory and the compiled code is accurate with the expected version
What I've done so far to troubleshoot, was to remove the extension completely. It does successfully update after a series of manifest.version updates, but then it goes stale. To be clear, all I do is update the version property of the manifest.json file and that seems to cause this issue
Any help would be greatly appreciated. In the meantime, I'll brush up on the architecture for service workers as it relates to chrome manifest v3. Thanks!
EDIT - Sunday, August 22 2021:
The latest development:
First of all, thanks woxxom for additional details to debug.
I've created an example project that demonstrates the problem with reproducible steps. Hopefully, this helps identify the problem but it does seem to point to a Chrome bug so I'll also report it on crbug.com
Github project: https://github.com/miguelespinoza/-v3-service-worker-update
Ultimately, what I've identified is that loading an iframe causes the service worker lifecycle to go "stale".
Looking at chrome://serviceworker-internals/?devtools, I've noticed that the extension includes two workers, that seems odd because I'd imagine only one should exist, the one in the background. This could mean nothing, but wanted to share that as well. one "Active worker" and one "Waiting worker"
Important Note: Service worker background events stop working. In my case, chrome.commands.onCommand or chrome.action.onClicked
I've executed update of Acumatica data base and faced following error messages:
For now I'd like to ignore all errors during update. Is there a way automatically to ignore all error messages during update of Acumatica database?
There is no way to ignore database errors as far as I know, but the error you are seeing seems related to temporary keys.
You could try to optimize the database before upgrading by going to SYSTEM->MANAGEMENT->MANAGE->Companies, selecting your company and clicking on "OPTIMIZE DATABASE".
Another option would be to temporarily disable constraints on the table that triggers the errors but I would test this before trying it on a production environment and you need to enable (rebuild) the index once you are done.
More info here: https://learn.microsoft.com/en-us/sql/relational-databases/indexes/disable-indexes-and-constraints
I recently installed GitLab to try it out and I am really enjoying it. It's very easy to install and use, still, I found an annoying "problem". I haven't yet found a way to delete Issues associated to projects.
I know that it's not a good practice to remove Issues from the system, but there are some specific occasions where this is really useful, such as when you create an Issue that makes no sense and don't want to be in the system, even after being closed.
So, my question, really simple: Is it possible to delete Issues on GitLab? If so, how can I do it?
I am using GitLab 7.2.1, on Debian wheezy.
Many thanks
It is now possible to delete issues starting with GitLab 8.6:
GitLab 8.6 released with Deploy to Kubernetes and Subscribe to Label
Delete Issues
Sometimes, simply closing an issue or merge request is not sufficient. For those times, we are now making it possible to delete issues and merge requests.
Only owners can delete issues by editing the issue or merge request and clicking, you guessed it, Delete.
At the time this question was asked, No. There is a feature request for that at: https://gitlab.com/gitlab-org/gitlab-ce/issues/2489
Now it seems possible: https://stackoverflow.com/a/36172116/895245
Click the Edit button (Pencil icon for editing the text of the issue)
Below and to the right of the text box where you can enter the description is a big red Delete button. Click it and confirm.
Personally, I find the hiding of a Delete button behind the Edit button and right next to a pretty unrelated Cancel button to be very unintuitive and weird.
You cannot do that any more.
Delete existing issue (Deprecated)
The function is deprecated and returns a 405 Method Not Allowed error
if called. An issue gets now closed and is done by calling PUT
/projects/:id/issues/:issue_id with parameter closed set to 1.
DELETE /projects/:id/issues/:issue_id
Parameters:
id (required) - The project ID
issue_id (required) - The ID of the
issue
Ref: GitLab Documentation
You can do that, but have to modify the database manually. If you have a backup, you can give it a try.
Update: Possible since GitLab 8.6.
I have an ASP.NET MVC5 website and I have installed Glimpse.MVC5 using nuget. The website is running the latest version of the Sitecore CMS (7.2 rev. 140314). I haven't changed the Glimpse configuration at all apart from adding logging.
When I go to the homepage of the website (after enabling Glimpse) I can't see the HUD. The following is the last line in the Glimpse log:
2014-04-24 15:19:01.6043 | DEBUG | Apparently GlimpseRuntime has not
yet initialized this request. This might happen in case you're doing
something specific like mentioned in this issue:
https://github.com/Glimpse/Glimpse/issues/703 . Either way, Glimpse
will be disabled to prevent any further non-deterministic behavior
during this request.
I've had a look at the link but I can't see that it applies to my situation. There are no NullReferenceException's in the log.
I have tested Glimpse.MVC5 with a vanilla ASP.NET MVC5 website on my machine and that worked fine so I'm tempted to assume that it's something to do with Sitecore.
Any ideas what could be wrong or ideas on how to identify the issue?
The solution mentioned in this post on the Glimpse issue tracker solved the problem.
Sitecore does it's own HttpModule stuff which seems to
cause issues.
In order to fix this, you need to move the Glimpse HttpModule
definition before the Sitecore modules in the Web.config.
The reason why you are still not seeing the HUD is explained by that log message as well.
Somehow during the execution of the request, a new HttpContext is created or used which means you'll loose the request initialization that Glimpse did at BeginRequest. As part of that initialization, items are being stored in the HttpContext.Items collection for which Glimpse will look during request monitoring.
The message you see in the log is an example of when Glimpse wants to know what the current RuntimePolicy is, so that it knows whether or not it should continue to monitor that request. The current RuntimePolicy is set by Glimpse during the BeginRequest phase of that request and the log now indicates it cannot find it, after which Glimpse decides to be concervative and stop monitoring that request instead of ending in a NullReferenceException
Now the cases where we've seen that (check the linked issues inside the issue you mentioned) is when another HttpContext is being created and used to process that request after that Glimpse did is initialization.
So the only advice I can give here, is to check whether the creation of another HttpContext is actually the case for you? You might find some ideas in those linked issues.
In case you find something specific that is not related to the issue mentioned above, then I would suggest you create a new issue on our issue tracker as it is a more appropriate place to discuss potential bugs or missing features
After installing a custom CLR object Sql Server Developer Tools (SSDT) VS2012 will not allow an update. The error is "Source schema drift detected. Press Compare to refresh. After refresh same thing happens.
Tried
In settings, I set the object to just Stored Procedures.
Settings ->General -> Block on possible data loss -> tried both on and off.
This sort of loop can also be caused by a referenced SSDT project failing to build. The referenced project may be missing, unloaded, or have an error which prevents the compare from completing.
This is not an answer but a clue to deal with this problem.
I was to update a colum from varchar[200] to varchar[MAX] and got this problem as well. So I logged in the server and tried to update the database manually via SQL Management Studio which was installed there, and I got this error:
"Saving changes is not permitted. The changes you have made require the folloing tables to be drpped and re-created. You have either made changes to a table that can't be re-created or enable the option Prevent saving changes that require the table to be re-created."
Seems that re-creating table is something so dangerous that "block/unblock on possible data lose" cannot handle. So I think only if we can walk around this LOCAL warning, could we update the database REMOTELY.
But, why [200] to [max] leads to re-creating table? It does not make any sense. I tried [200] to [1000], and it did not work as well. This might be the key to this problem.
And, if you do the same update in Server explorer in VS, instead of SQL Management Studio, it works. Again, why?
This can happen when a db user "changes".
The following rather scary forum page recounts issues where foreign hackers were trying to brute-force access to the "sa" db user, with each attempt changing the sa-user's date timestamp (which is seen as a schema drift):
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/5c22a7b4-7a82-4717-a118-2475bc62705b/schema-compareupdate-error-target-schema-drift-detected?forum=ssdt
Here is also mentioned that you can query the sa-user a few times, to see if this is happening to you:
SELECT * FROM sys.server_principals WHERE principal_id=1
I am currently experiencing the same issue (that the sa-user is being modified; I know nothing about hackers yet) and am yet to find a solution.
Edit - I turned on logging in Windows Firewall via properties > logging, and we setup a blocking rule on port 3071, which had a lot of unexplained traffic. Then the problem went away.
I tried running VS as an administrator, it worked.