Lock table overflow problem

[theom]

Hi,

I have an application which runs under Progress 8.3b, character version. The server runs under NT, clients under W2K.
In have setup a W2K test environment for the db server. Clients, parameters, program library, etc. is exactly the same as under NT.

Under NT the applic works fine, but under W2K I have the problem that every now and then the application crashes. Message is "Lock table overflow, increase -L on server (915)". I have -L increased to 30000 but it doesn't help. I have also added extra memory to the server (now 256 Mb), but this doesn't help either.

Who can help me? Do I need to recompile the application (allthough the db isn't changed)?

Thanks, theom.

 

[richtpt]

Are there any other messages in the .lg file right before the lock table overflow? Memory shouldn't have anything to do with it. This error is usually a run-away transaction. Tell us a little more about your application, what you're doing when you get the error, client and server startup parameters.

And you say when you do the same exact thing on the NT server, it works fine, right? Are you running the same exact .r code on the NT server as you are on the W2K client? Are the client startup parameters the same for both NT server and W2K client? in other words, is everything exactly the same except for the OS?

Rich

 

[theom]

Correct, everything is exactly the same except for the OS. The applic is an admin system for drawings. Upon user entry the application inserts a new drawing record in a main table plus a number of records in subsequent tables.
There is no error message at the client side, the programs just bombs out. At the server the message as listed above is shown in the event log.

Server parameters:
-N TCP
-S PIAS
-H NLLUMLGNA0121
-L 20000
-Mm 512

Client parameters:
-d dmy
-p amsmmenu.p
-e 63
-l 63
-s 20
-D 150
-L 3000
-Mm 512
-yy 1930
-v6q
-v6colon
-T C:\TEMP
-db PIAS -N TCP -S PIAS -H NLLUMLGNA0121

At this moment I am debugging the .p file (pause staments) to see how far it gets.

 

[richtpt]

Just to clarify. Are you getting that error message from the Windows Event Log or from the database .lg file? I'm just curious to see if there are any other messages in the .lg file before the lock table overflow that might indicate something strange going on.

Also, -L is a server only parameter, it won't have any affect on the client, so you can remove it from you client parameters.

Here's the text from the Progress KBase #3284 about this error, maybe something here can shed some light too.

Rich



How to debug "Increase -L" error,record locking,transactions

900531-hjb01

INTRODUCTION: Date Last Modified: 6/26/90
=============
This Product Services Technical Support Knowledgebase entry details the causes and corrective measures to take if you encounter PROGRESS errors 915 or 429. It explains record locking and scoping issues as related to the size of PROGRESS transactions.


POSSIBLE CAUSE OF ERROR:
========================
The application is locking more records than the server startup parameter (-L) currently allows. If you do not specify -L as a startup parameter on the PROGRESS SERVER (proserve command), PROGRESS sets the default number of locks to 500.

The most likely reasons that PROGRESS is locking a large number of records are:

1) The transaction is very large.

-OR-

2) The records are being held SHARE-LOCKed after the
transaction because the record scope has not ended.


DOES ERROR INDICATE CORRUPTION: IF SO, WHAT TYPE:
=============================== =================
NO N/A


CORRECTIVE MEASURES:
===================
Increasing the -L startup parameter on the PROGRESS SERVER (proserve command) gets around the problem, but more records remain locked thus creating a greater likelihood of other users attempting to access locked records.

Running the procedure in single-user bypasses PROGRESS record-locking. If your process involves a large transaction and you do not want to exclude active users from updating locked records, consider running the process in single-user, batch, or both at a time when users are not actively updating records.

Making transactions smaller within your procedure locks fewer records and avoids having to increase the lock table (-L) startup parameter. One method of lowering the scope of your transaction is to put a DO TRANSACTION: block directly around the statement that updates the record. If the scope of the record you are updating is higher than the scope of the transaction, however, PROGRESS holds on to a SHARE-LOCK for each record until the end of the record scope. The RELEASE statement allows you to explicitly release a SHARE-LOCKed record after the statement which updates the database has occurred.

What is a record's scope? The block in which it was first referenced in your procedure or in a calling procedure. Use the COMPILE with the LISTING option to determine a record's scope. Note that any reference to a record, before the first block in the program, scopes that record to the procedure block.The procedure block does not end until program end. Therefore record locks being held until the end of the record scope are held for the duration of the program unless you explicitly release the lock with the RELEASE statement.

What is transaction scope? The outermost block with transaction properties that updates the database. Statements that update the database include: UPDATE, CREATE, ASSIGN and SET. Blocks with transaction properties include: FOR EACH, REPEAT, PROCEDURE, DO TRANSACTION, a block that specifies EXCLUSIVE-LOCK and any block that has the TRANSACTION keyword. Use the PROGRESS istrans.p procedure to determine if there is already an active transaction in your procedure (see next paragraph for details). Note that PROGRESS allows only one active transaction at a time, so the next transaction that you start in your procedure is actually a subtransation. Also note that if you start a transaction in one procedure and it has not ended when you call a sub-procedure, new transactions in the sub-procedure will also be subtransactions.



ONLINE PROCEDURES OR UTILITIES:
===============================
You can run the debugging procedure istrans.p anywhere from within your program to determine if there is a transaction active. To get a copy of istrans.p (PROGRESS version 5 and above) go to the Procedure Library from PROGRESS HELP and EXTRACT PROCEDURE istrans.p from the TOOLS library. In PROGRESS versions prior to 5, RUN unpack.p from the PROGRESS Editor and specify istrans.p as the procedure to unpack.

The Database Monitor - Option 4 Record Lock Table. The monitor displays current record locks being held. (PROGRESS version 5 and after only). See The PROGRESS System Administrator's Guide for information on how to use this utility.

The COMPILE LISTING option gives information on where records and transactions within your program are scoped.


REFERENCES TO WRITTEN DOCUMENTATION:
====================================
Programming Handbook - Chapter on Multi-user Applications
Programming Handbook - Chapter on Transactions
Programming Handbook - References to istrans.p in index
System Administration Guide - Chapter on the PROGRESS Monitor
Reference - COMPILE with LISTING option
Progress Software Technical Support Note # 3284