# QAD "Lock Table Overflow, Increase -L on Server (915)": Cause and Fix > Source: https://netray.co/erp-help/qad-progress-error-915-lock-table-overflow-increase-l > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## 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. ## Kind error ## System small-erp ## Erp QAD Enterprise Applications (Progress OpenEdge database) ## Module System Administration - Database Locking ## Query QAD Lock table overflow, increase -L on server (915) ## Alternate Queries - Progress error 915 lock table overflow - QAD mrp regeneration lock table overflow - OpenEdge increase -L startup parameter - QAD batch job fails lock table overflow ## 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. ## Steps ### How to resolve error 915 **Items:** Note 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. Check 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. In 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. If 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. If 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. Shut 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. Rerun the failed job and watch the lock table during the run, so you know how much headroom you have. Document the new value in your runbook so a future database rebuild or migration does not silently reset it to the default. ## Sections ### What the lock table is and why it fills **Body:** 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 **Body:** 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. **Code:** - # 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 **Body:** 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 **Body:** 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. ## 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. ## Ai Angle 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. ## Faq ### What is the default value of -L in Progress? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms QAD lock table overflow, Progress error 915, increase -L on server, OpenEdge -L startup parameter, QAD MRP regeneration error, promon record locking table, QAD CIM load fails, proserve startup parameters, QAD database administration, Progress lock table size --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json