QAD "Lock Table Overflow, Increase -L on Server (915)": Cause and Fix
QAD Lock table overflow, increase -L on server (915)
Also searched as
- Progress error 915 lock table overflow
- QAD mrp regeneration lock table overflow
- OpenEdge increase -L startup parameter
- QAD batch job fails lock table overflow
Short answer
Progress error 915 means the database server ran out of entries in its shared record lock table, which is sized by the -L startup parameter. Either one session holds an enormous number of record locks inside a single transaction, or -L is simply too small for your workload. Find the session first, then raise -L in the database startup parameters and restart the database.
Applies to: QAD Enterprise Applications (MFG/PRO through QAD Adaptive ERP) on Progress OpenEdge 10.x, 11.x and 12.x databases, on Linux, AIX or Windows servers.
How to resolve error 915
- 1Note which program and user raised the error. Batch programs such as MRP regeneration, cost rollups, or large period-end postings are the usual triggers, not interactive screens.
- 2Check the current -L value. Look at the database startup parameter file (.pf) used by proserve, or run promon against the database and read the startup parameters display.
- 3In promon, open the R&D menu, then Status Displays, and view the Record Locking Table. Identify the user number holding the largest number of locks.
- 4If one session holds a huge share of the table, treat that as a program problem: a transaction scope that is too wide, not a parameter problem. Ask the developer or vendor whether the program can commit in smaller units.
- 5If the load is legitimate, increase -L in the .pf file. Common values for mid-size QAD sites run from the low hundreds of thousands to a few million entries, depending on batch size and memory.
- 6Shut down the database cleanly with proshut and restart it with proserve using the updated parameter file. -L cannot be changed while the database is running.
- 7Rerun the failed job and watch the lock table during the run, so you know how much headroom you have.
- 8Document the new value in your runbook so a future database rebuild or migration does not silently reset it to the default.
What the lock table is and why it fills
Every record a Progress client locks inside a transaction takes one entry in a shared lock table held in database server memory. The size of that table is set by the -L startup parameter, and the default is small (a few thousand entries). When a transaction needs a lock and the table is full, the server raises error 915 and the transaction is backed out.
In QAD this rarely comes from normal data entry. It comes from programs that read and update many records in one transaction: MRP regeneration touching thousands of planned orders, a cost roll processing a whole product structure, or a mass update run through a CIM load that wraps the whole file in one transaction.
Progress holds locks until the outermost transaction ends. A loop that updates a hundred thousand records inside one DO TRANSACTION block therefore needs a hundred thousand lock entries at once, even if each individual record is touched only briefly.
Finding the session responsible
Before raising -L, find out whether you are looking at a normal workload or a runaway program. In promon, the Record Locking Table display lists each lock with the user number, table, and lock type. Sort the output by user number and count how many entries each session holds. One user with tens of thousands of locks while everyone else holds a few dozen is the signature of a wide transaction.
Cross-reference the user number with the User Control display to get the login name and process id. On the OS side, the process id leads you to the QAD batch job or background process that owns it.
Do this while the job is running, not afterwards. The lock table is only a snapshot of the current moment, so run the display repeatedly as the batch grows.
# Typical startup parameter file fragment (QAD database .pf) -db /qad/db/mfgpro -S mfgpro_svc -B 500000 -L 2000000 -n 300 -spin 5000
# Start promon against the running database promon /qad/db/mfgpro # Then: R&D -> 1. Status Displays -> Record Locking Table
Sizing -L without wasting memory
Each lock table entry consumes a small, fixed amount of shared memory, so raising -L from the default to a couple of million entries costs well under a few hundred megabytes on modern servers. The cost is real but usually modest compared with the buffer pool set by -B.
Do not set -L to an arbitrarily huge number as a reflex. A very large lock table hides a badly designed transaction, and it also means one runaway session can hold locks that block interactive users for much longer before anything fails visibly.
A practical approach: measure the peak lock count during your heaviest month-end run, then set -L to roughly twice that peak. Revisit it when you add major volume, a new plant, or a new batch process.
Fixing the program instead of the parameter
If the culprit is custom code or a CIM load, the durable fix is to commit in smaller units. In ABL this usually means moving the transaction scope inside the loop, so each record or small batch is its own transaction, and releasing record locks explicitly where appropriate.
For CIM loads, split the input file into chunks and load each chunk as a separate run. This also gives you a restart point if something fails halfway through.
For standard QAD programs, raise the issue with QAD support or your reseller with the exact program name, data volume and database -L value. Standard programs are normally tested against typical volumes, so a very large site may genuinely need a larger -L.
Common pitfalls
- !Changing -L in the .pf file but forgetting to restart the database, so the old value stays in force.
- !Editing the wrong .pf file when a site has separate files for brokers, batch servers and utilities.
- !Setting -L far above what the job needs and masking a wide transaction that will block other users.
- !Fixing it only on production and not on test and training databases, so the failure resurfaces after the next refresh.
- !Assuming the lock overflow is a hardware or memory fault. It is a configured limit being exceeded.
How an ERP-grounded AI assistant handles this
An assistant grounded in QAD and the Progress environment can take the error text and the job name, then suggest the likely wide-transaction programs, walk you through the promon displays to check, and draft the .pf change for review. With ERPray-style read-only access it can also summarize which batch jobs ran at the time of the error. It should never restart a database or edit parameter files on its own: those steps stay with your DBA.
Frequently asked questions
What is the default value of -L in Progress?
The default is small, in the range of several thousand lock entries, which is fine for light interactive use but far too low for batch programs in a manufacturing ERP. Most QAD installations set -L explicitly in the database startup parameter file, so check the file in use rather than assuming the default.
Can I change -L while the database is running?
No. The lock table is allocated in shared memory when the database starts. You must shut the database down with proshut and restart it with proserve using a larger -L value. Plan the change for a maintenance window, since all users and batch jobs will be disconnected.
Does error 915 corrupt data?
No. Progress backs out the failing transaction, so the data stays consistent. The visible damage is that the job did not complete. Check whether the job left partial results in a different transaction scope and rerun it after the fix, ideally with a note of what was already processed.
Why does it only happen at month end?
Month-end and period-close jobs process the largest sets of records in a single run, such as full cost rolls or large postings. They push the peak lock count much higher than daily activity does, so a table that is sufficient all month overflows exactly when volumes peak.
Related
QAD Says "Unable to Connect to the Application Server": How to Fix It
This error almost always means the Progress OpenEdge AppServer broker behind QAD is stopped, unreachable over the network, or out of licensed connections, not a database problem. Confirm the broker process is running and healthy in OpenEdge Explorer, check the port and firewall path from the client, then restart the broker with clean agent settings.
Error fixQAD Progress BI File Growing Huge: Causes and How to Truncate It
The before-image (.bi) file grows when Progress cannot reuse its clusters, usually because a long-running transaction is still open or the cluster size is too small. Find the oldest open transaction, end it, then if the file is still oversized do a clean shutdown and run proutil truncate bi with a sensible cluster size. Never delete the .bi file by hand.
How-toHow to Back Up and Restore a QAD Progress Database with probkup and prorest
Use probkup online to take a consistent full backup of a running QAD database, add incremental backups between fulls, verify the backup with prorest -vp, and restore with prorest into a prepared structure. A file-level copy of a running database is not a valid backup. Pair backups with after-imaging if you need point-in-time recovery.
How-toHow to Create a Generic Inquiry in Acumatica
Generic Inquiries (GI) are Acumatica's no-code query builder for joining tables, adding filters, and exposing the result as an inquiry screen, dashboard data source, or API endpoint. Open System > Customization > Generic Inquiry, add your base table, define joins and conditions, then run and save. No SQL or customization project is required.
Error fixFix Odoo AccessError: You Are Not Allowed to Access Records
Odoo raises AccessError when a user's security groups do not grant a CRUD right on a model through ir.model.access.csv, or when an ir.rule record rule filters the specific record out for that user or company. Fix it by adding the user to the group named in the error, editing the model's access rights, or reviewing the record rule's domain under Settings > Technical > Security.
How-toHow to Void a Check in Sage 100
Sage 100 voids checks through Accounts Payable > Main > Check and Payment Voiding. Select the bank code, choose the check number, and Sage reverses the Cash Disbursements Journal entry and reopens the invoice it paid. A check that already cleared in Bank Reconciliation or falls in a closed period needs an extra step before it can be voided cleanly.
AI for ERPAI for QAD Adaptive ERP in automotive and industrial manufacturing
Add AI to QAD Adaptive ERP or Enterprise Edition for automotive and industrial manufacturing, grounded on QXtend and QAD's API layer, on-prem or private cloud.
AI for ERPAI for QAD in Automotive: Schedules, Traceability and IATF Evidence From Your Own OpenEdge Data
Private AI on QAD Adaptive ERP for automotive suppliers: schedule releases, ASN, lot traceability and IATF 16949 evidence, read-only, on-prem or sovereign.
Stuck on QAD Enterprise Applications (Progress OpenEdge database)?
Talk to engineers who work inside QAD Enterprise Applications (Progress OpenEdge database) every week, and who build private AI that answers these questions from your own ERP data.