Lock Table Overflows (Argghhhhhh)

[jamesmc]

Hi All,

I seem to be having a little problem that I just can't get my head round.

I have a program (dataload.p) that creates or updates loads of records in my Progress database. If I run the program from the character editor the data loads OK with no more than seven records being locked at any one time.

If I run the same program (dataload.p) from a scheduler that we have it also runs OK with only six or seven records being locked at any one time.

If I then run the update program (dataload.p) from a different program (nightly.p) that runs from the scheduler I get a Lock Table Overflow as it seems that dataload.p doesn't release any locks.

The scheduler and nightly.p call the program in the same way (run value(dataload.p)) but it seems that each program handles the record locking differently. How is this.

I have tryed to add release statements into the code to release the exclusively locked records when it has finished with then but no joy.

If anyone wants any code examples then let me know and I will forward some on.

Database/Scheduler and code all running on IBM AIX, Progress v8.3b.

Thanks,

James.

 

[JimcDTWabs]

RE:Argghhhhhh

At first perusal, sounds like the old "Transaction Scope" gambit.

An outer transaction mustn't obey an inner release statement.

I will assume the Progress defaults in place due to your normal usage of the language have noticed an "outer" transaction scope issue and applied such sensible defaults. Perhaps it's a message from Deity? What would be the suffer if only some of your records were loaded and you had not also coded to "know" what, where, when, etc. had NOT worked, and "progressed" along with a state of missing records going unnoticed?

Progress was created (cloned actually) in a Unix (BSD I think) envoronment where "sensible defaults" was paradigm prime.

TRY: In the "inner" procedure, explicit use of the "transaction" keyword for the iterating block I must assume you have there.

The Programmming Handbook etc. info on making transactions smaller specifactly (sic) address the issue I have raised. But, as I apprised above, it seems, from your statements, it really is an "outer" transaction requirement, or should be for enabling the code you spent time on for reliable and further loading issues.

The solution seems likely to be a divide and conquer AND provide some outer protocol for errors in transmission with retransmission, which may belong in the "outer" procedure.

My suggestion:

1) Make the transaction be inside the inner procedure.
A nice vanilla loader, useful as a component, tool, object, etc.
that just deals with that (it's) business.

2) Write an outer procedure that manages integrity of transfers
for completeness, confirmation, retry, etc.

3) Instead of coding options inside any procedure, code in
parameters that cause "outer" includes, procedures,
recursions, etc. to employ such other functions via params.

4) Such use of parameters should ultimately provide for all of
1) thru 3) above to be called in outer drivers by mbpro OR a
user interface (that's getting way cool).

Not providing for transmission completeness (which is pretty much what transactions are all about; surety) could make "outer" use of ANY loader a career breaker.

Notification of transmission errors then becomes the next issue.

But if that isn't any part of you actial (still sic) problem,

nevermind.

SOOOOOOOORRRRYYYYYYY.

Regards,

Jim Cunningham

P.S.

In the inner procedure smallerd transaction scope, look for advantage to take of transaction scope to still write a lot of records and cut way down on processing overhead in all aspects. Just know the scope and be in control. If I had to maintain the code later, I might be brusque and chide you for not being explicit in apprising me of all this, in the code itself. A manager might chide more fatefully.