I’ve found that background jobs can hide a lot of errors whenever TRANSACTION_SYS shows up in the error stack, so my first thought here is usually to run it live. However, this particular procedure detects whether it’s being run as a background job and will spawn itself as a job if it isn’t. This makes troubleshooting annoying because you can’t run it live from the GUI. If you have access to the app owner, you might try this hacky workaround in Oracle. The idea is to make it think it’s running as a background job so it runs live, selecting a negative background job ID that will never exist.(Using a raw DELETE query like this is not considered a best practice, so if you can, it would be best if you could refresh a nonproduction environment and try it there.)BEGIN DELETE FROM transaction_sys_local_tab WHERE id = -1; DELETE FROM transaction_sys_status_tab WHERE id = -1; transaction_sys.set_current_job_id(-1); mpccom_accounting_api.transfer_to_finance ( contract_ =>
Apps9 - UPD deploying failed on the customer non-prod environment. Work without error on customer Apps9 internal environment. If you use DataPump as the SYSTEM user, it won’t include grants on SYS objects and won’t include system privileges. I recommend doing nonproduction copies with RMAN instead.
MOS 2118028.1 tries to explain this, but they only cover the zero case: If it's zero in the CDB, then the scheduler is disabled in all PDBs, but if it's zero in the PDB, it's only disabled in that one particular PDB. It looks like the CDB value works as a ceiling. If that’s true, I think we should set the CDB value astronomically high, like the Oracle default value of 4000, then fine tune the PDB value. If anyone disagrees, I would like an in-depth explanation for why. I may come back here with more details if I get a chance to test this more fully.
From the Oracle Database 21 documentation:https://docs.oracle.com/en/database/oracle/oracle-database/21/refrn/JOB_QUEUE_PROCESSES.html “In a CDB root: Set JOB_QUEUE_PROCESSES to the maximum number of job slaves that can be used simultaneously in the entire CDB. Oracle recommends that you set the value of this parameter to at least twice the number of open containers in the CDB, otherwise, there might be severe starvation between PDBs trying to run multiple jobs. If JOB_QUEUE_PROCESSES is set to 0 in a CDB root, then DBMS_JOB and Oracle Scheduler jobs cannot run in the CDB root or in any PDB, regardless of the JOB_QUEUE_PROCESSES setting at the PDB level. “In a PDB: Set JOB_QUEUE_PROCESSES to the maximum number of job slaves that can be used simultaneously in the PDB. The actual number depends on the resources assigned by Resource Manager and the demand in other containers. When multiple PDBs request jobs, Oracle Scheduler attempts to give all PDBs a fair share of the processes. Oracle
As far as I know, other application owners are “supported”, but “support” in this context is nothing more than a piece of paper that tells everyone where to point fingers. If you don’t actually get help, supportability is worthless. (Sure, you could take a vendor to court, but how often are you willing to do that, and how helpful will it really be when your system is down in the meantime? In my opinion, you’re better off building good relationships rather than being adversarial and pedantic.)After I found IFSAPP hard-coded in an early version of Cloud, I made the decision that I didn’t want to be caught having to beg for help for a weird configuration some day. It felt safer to conform, and an upgrade this big, for 9 to Cloud, provides us a rare opportunity to make such a change. (There weren’t enough changes from 8 to 9 to justify something as disruptive as this.)If you ever have to go shopping for auto parts, even if your local parts store claims to carry every brand, would you rathe
Nonstandard application owners were only a common practice in North America, and no new implementations are going that way now.
Exchange Online removed all forms of Basic auth as of 2022-12-31, with Client Submission (SMTP AUTH) being the only exception.https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-online-to-retire-basic-auth-for-client-submission-smtp/ba-p/4114750SMTP AUTH is now off by default and will be completely going away in September 2025.https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365We're already looking to move our email tenant to reduce our spend, and it's going to cost us extra money to keep an ERP around that can't support this.
Is this working yet?
Already have an account? Login
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.