This content has been marked as final. Show 21 replies
No, the bean timer would not help at all. ItsSorry if I mentioned the bean timer, in this case it would be not very useful.
function is not to refresh anything, but only to act
as a Forms internal timer.
I remember how I used it :
It was to avoid fast repeating timer in forms, making a quick select to dectect changes in the table and if so execute query and of course synchronize..
maybe checkings paramaters like heartbeat, forms_timout can help?
in modern times like today we all have to deal with multi-processing, multi-posting and shared answering to crossing posts :-)
and in future? we have to program a little tiny tool, which answers for us !
> I've problem straight away running the sample form with the ORA-92102 error. I've used
the same code as I've posted at the beginning of this post for the sample form and when
it ran, it just failed with ORA-92102 without refreshing my text item for even once.
Does that mean you got the error WITH or WITHOUT the synchronize?
By the way, what that process is doing is a really bad use of the form. All it is doing is stepping through all the rows of the cursor, and flashing the client id in the field on the screen. The screen refresh is probably taking 100 to 1000 times longer than the time required to fetch the client's id from the cursor.
Oracle gathers ALL the rows for a cursor when the initial select statement is executed. All the rows are collected into memory before it ever responds to the form's request that the data is ready to be fetched. So flashing the message, "Processing this client: nnnnn" is false information anyway.
Get rid of the loop and replace it with a counter. When the loop is finished, put a message on the form saying something like "Number of clients processed: nnnn". It will run in an instant, unless the cursor causes Oracle to do a full-table-scan, or something bad like that.
I got the error with the 'SYNCHRONIZE' command. Actually my loop was:
FOR CLT IN FIND_CLIENTS LOOP
:block.item1 := 'Processing client: ' || CLT.CLT_NAME;
:SYSTEM.MESSAGE_LEVEL := 5;
:SYSTEM.MESSAGE_LEVEL := 0;
In regard to your propose changes, can you please spare some time to tweak the loop above accordingly as I'm not quite sure about your 'counter' implementation? Thank you for your assistance.
Here is what I would use:
I would only commit after the entire process is completed. Committing after each client is processed is inefficient for the database.
Declare Loop_count number := 0; Begin FOR CLT IN FIND_CLIENTS LOOP --:block.item1 := 'Processing client: ' || CLT.CLT_NAME; --synchronize; Loop_count := Loop_count + 1; some_package.perform_something_to_this_client(CLT.CLT_NUMBER); END LOOP; :SYSTEM.MESSAGE_LEVEL := 5; COMMIT_FORM; :SYSTEM.MESSAGE_LEVEL := 0; :block.item1 := 'Processed ' || Loop_count || ' clients'; End;
I think SYNCHRONIZE should be placed appropriately in the code in 10G applications. Oracle does not recommend removing SYNCHRONIZE completely in 10G. Its just that a 10G application is using Application server technology whereas the way SYNCHRONIZE was used previously in Forms 4.5 was different since it was used in Client server technology.
SYNCHRONIZE was there during the SQL*Forms 3.0 years as well.
It still has some facilities, we discovered that during some Java crasches recently...