Search results

mixed bag of 11.7.x to 12.x.x. Sounds like an excellent way to get in all sorts of difficult trouble.

I.e., it would help a lot if we knew the business problem you were trying to solve.

I recommend that you think carefully about what you really need. For example, I can understand wanting to undo everything about a customer and their orders, while leaving everything about all other customers and their orders, plus treating the delivery flow as a separate transaction. What you...

The solution, of course, is to change the transaction scope. Making the entire do block one transaction is obviously going to lock a LOT of records with those kind of numbers. What is not obvious is what scope is appropriate for your business needs. Possibly you could process the orders for...

Recently, the site has been very slow when first accessed. Today it is worse and everything is slow. Images are especially slow. Are we down to connecting with a 300 baud modem?

You might want to try the QAD forum.

Think of the FOR EACH returning a set. In the above code, the set is empty, so the enclosed code never executes. With the FIND, it is either going to find a record matching the criteria or not, but it will always proceed to the next line, so the not available is reported. Indeed, were I...

There is a Syteline board.

You should also think real hard about the value you are going to get by deleting data. Once deleted, it is no longer available for query and reporting ... you are losing information. Disk is cheap.

The other thing that screams to me from your code is transaction scope.

"Architect_Is_Runnig"

I was going to note that it is architecture specific. An application that fetches lots of records ... whether necessary or not ... will be significantly faster with shared memory than TCP, whereas one that fetches minimal records and minimal fields may not contrast nearly as much.

If it is supposed to be the fix, it is an awful fix.

Click on the tab in the upper right with your username and select account details.

Note to be very clear that the message is telling you that all the updates were a part of a single transaction and that explain running out of lock table space.

Or use the difference tool...

Reread my second sentence and look up PUT.

You don't say how you are doing the display, but if it is something like a loop with a display, then do one display of the first 6 and then test for non-null before displaying the 7th. This will, of course, require appropriate verbs for display that will allow you to keep control.

There is also a QAD forum on ProgressTalk. They might have more of a clue.

Why not just put both updates within the same transaction ... and, turn off pstimer and any possible user input while running that transaction?