Search results

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?

A clear explanation of what you want or what you are trying to fix would help.

Clearly, a bit more context would make this clearer. Show the enclosing block ... at least the top, possibly skipping any non-problematic code between the top of the block and the code in question.

Isn't the fact that the URL arrives in an e-mail irrelevant? Isn't the requirement actually to just launch an Open Edge session from a URL and pass in a record identifier to initialize the display?

You might start by telling us why in the world you want to do such a thing.

If so, there is a forum for it here.

You might start by asking yourself whether 10K records in a browse is actually the best user interface.

As he said, by identifying a resource that will be able to guide you. This is not something that can be covered in a post or two. And the process will depend a lot on the current architecture of your system ... and your budget. For starters you are going to want to be on a current release of...

With the strong scope, the release is pointless.

Yes, it has been quite a while now, but as I remember we uploaded the picking list to the gun while it was in the dock and then downloaded the results. I think the dock was nothing more than a dumb connection and I think the port on the local computer was actually connected via the OS to a...

When I have done this in the past ... a fairly distant pass ... we were using scanners with a docking station so that the warehouse people could go all over the warehouse and then return to the docking station. The docking station was connected to a PC, possibly USB, possibly serial, and it...

Point being that with the strong scope, you don't need to worry or query about the availability of the buffer outside of the strong scope because you know the buffer isn't available there. For the sake of satisfying yourself, you could define a second strong scope block there and test...