I'm using SPJobDefinition.Execute to explicitly force a timer job to run for a bit of testing. The job runs but the time it last ran hasn't changed in either 'Timer job status' or 'Timer job definitions'. As this hasn't run before, forcing it doesn't even appear in 'Timer job status'. I recall that it did update the last run time inside central admin when I last tried this. So either something is broken and it's not updating the status, or it doesn't update the status by design and I'm mistaken about it doing so last time.
I've discovered that OWSTIMER.exe doesn't end up doing the execution. I wrote a console app which did the call to SPJobDefinition.Execute and it turns out that Execute doesn't schedule it to run there and then, but actually loads up the dll for the job and runs it in process. I would imagine that a side effect of this is that it doesn't run under schedule and so Central Admin doesn't show that it ran.
I had similar problem, the solution was to restart the 'SharePoint 2010 Timer' service (to reload the job DLL).
Related
I have a development instance on my laptop and for some reason I cannot get any Automation schedules to fire. If I create a schedule, it looks ok and shows the appropriate next execution time, but it never changes. What am I missing to enable the scheduler?
If you restored a snapshot on your site, you will need to go to screen Automation Schedules screen (SM205030) and click on Initialize Scheduler action.
This action exists in order to prevent schedules to be run directly after restoring a backup of an environment.
This was done to prevent necessary actions from happening on a test environement, e.g. spamming customers email, uploading important files to file provider, etc.
This is why this button need to be manually clicked after restoring a backup.
With the help of support, I was able to resolve this. We deleted the application from the configuration manager and recreated it. The scheduler then started working. There was nothing obviously wrong, but creating the new instance worked.
I deployed a user event script, which applies to Purchase Orders, with event "edit".
My script ran the first time I edited a purchase order, but thereafter it no longer ran. I recreated the entire script and deployment, but it is still not running.
I checked the list of scripts applied to purchase orders and my script is there. The script is deployed and released, with event type set to 'edit'.
Might this have something to do with usage limits? There was an error during the first execution of the script, where I did not supply a needed parameter, perhaps this caused an issue?
Any help will be greatly appreciated, thank you.
Did you select an audience when you released the script? If there is no audience selected, the script won't execute. Happened to me a couple of times.
I have a client that is trying to run the Validate Customer Balances process in accounts receivable and the process does not finish. What tools are available to debug this?
First of all you need to determine whether the process finishes with an error or is simply taking a long time.
This process has a specific warning stating that balance validation takes a long time:
If you see the process progress indicator spinning, it's most likely just taking a long time. In that case you should either wait until the process finishes or follow the warning to select fewer customer.
If the processes finishes with an error indicator:
Open the trace window and run the process again, error details are usually visible in traces. For example, if you see financial period is inactive in traces then you can resolve it by going to the financial period screen and activating it:
Acumatica's T190 Quick Start In Customization and T270 Workflow API documentations describe the Debugging Process while working with Acumatica.
When you install a new Acumatica version, You must put the Install Debugger Tool checkbox.
You must open Visual Studio project as Admin.
To be able to debug the site's original source code, find web.config file of the Acumatica instance. Setting of Vistal Studio also must be changed as described in documentation.
Change the "False" value to "True".
Go to Debug->Attach to Process... or press Ctrl+Alt+P. Search for w3wp.exe, select the instance you needed and Press Attach.
Then put breakpoints and do debugging as you would do in any other project not related to Acumatica.
We are transitioning to DNN 9.01.01 build, but it seems that the import/export feature is not working properly. I submitted an import but it has been sitting on submitted status for the last 8 hours.
Is this a known issue or is there configuration on the server that preventing the import/export to work?
Our instance is installed on Azure
Thanks
This thread hasn't been touched in a long time but I dug around and found the problem. I fixed this problem by directly editing the DNN database. I'm on version 9.4 although, I'm sure this would work with any version as this issue is apparently caused some wonky code in the Azure AppService deployment packages.
To resolve, I just had to manually edit the dbo.Schedule table. I use Azure Data Studio because I'm on a Mac but SSMS or any other manager will work as well. I'm sure you can even use the DNN built-in editor although I'm not very familiar with it.
While digging through the dependencies I noticed that unlike the non-operational Export/Import job, all the working jobs had a NULL value in the "Server" field whereas the Export/Import job had the Azure server name written to it. I manually changed the value of this field to NULL and the Site Import job that had been perpetually spinning, started immediately.
Also, for posterity, you will want to make sure you don't have 15 different import jobs queued up before you do this because they will ALL begin processing once you commit the new value to the DB. If it took you a few times to figure out they were spinning you will probably want to go to the scheduler and delete anything you don't want to run prior to the DB edit.
Hope this helps save someone else some time. Cheers!
We contacted support as well and looks like it was an issue with installing DNN as Azure webapps.
We had to delete all the unused server and set the task to run on the current active server and start the import/export feature manually on the scheduler tab.
I had this issue, when checking the other task scheduled for execution I noticed the server field was empty while on the import/export there were comma separated inputs. When I cleared the import/export field the task ran correctly.
I believe they left out coded for this I'm DNN 9. I tried using it for a customer and it was useless.
I inquired and got a response that said it was an oversight.
To add to the possible issues that can cause this, We had renamed our server and the scheduled task still had the original name of the server. Once we changed the name to the new one under the task, it started running as scheduled.
HTH
Dave
I wrote an agent that runs every 1:00 AM daily, but fails to execute the routine mysteriously. I've checked the agent log and saw that it ran and ends without any error. What I've been thinking about is when I trigger the agent or ran it manually it executes the routine I coded successfully and not when it is scheduled. I really don't know what's the issue there, thanks for help in advance.
there are a few things to try
Check the trigger property on the agent and set it to run on All documents or change it to None. Test both scenarios. There are some issues with this setting.
When you run an agent manually from the notes client or designer you are running it using the credentials from you id file. When running it scheduled you use the credentials from the server.
Make sure your server have enough access to perform what your script does. There is also a setting in the agent for increasing what the script is allowed to perform.
If you have access to the server console you can trigger the agent to run on server using the command: tell amgr run "database.nsf" 'agentname'