Situation: I currently have a page that is a type of Dashboard page. It contains several charts and reports. This page is the home page of the application. When the page first loads a Request Type of First is passed into the page. As the page renders several page processes calling Oracle Package, setting values, etc are executed. Once the page processes are complete, i believe the dynamic actions are then fired off. There are probably 10 DA's that are fired on PageLoad. The very first DA is fires on PageLoad but has a condition of REQUEST = 'First'. If condition is met, the page is then resubmitted with a Request Type of: search.
Question: How does APEX process Dynamic Actions, specifically PageLoad? If there are 10 Dynamic Actions all sequences are greater then another, does APEX or Page Processing handle one at a time or do they all execute at the same time regardless of sequence and conditions?
Reason for Question: I created a DA to execute an insert statement into a DB Table. This DA executes on page load with no conditions and is sequence#: 0. Then, i created another DA to do the same but is the very last sequence#. When logged into the application and then viewed the data inserted into the DB table, it showed both records 4 times. the first two were inserted when request type = First. Then the DA already mentioned fired and resubmitted the page which then inserted two more records. I was only expecting three records to be in the DB Table. One for the request type First and two for the request type search.
Why are you using dynamic actions? Why not use processes that execute during page render?
Dynamic action execute order can't be guaranteed in that way, in the same way has a JavaScript loop behaves like nothing you'd think. JavaScript does it's own thing.
If you're executing PL/SQL in your dynamic actions, this will behave synchronously or asynchronously. Either way, they will be launched with x separate processes. The only way to control order would be to have them in the same dynamic action and 'wait for result' set to yes.
Which brings me back to: why use dynamic actions?
Related
Good day everyone,
we are trying to have through the use of the integrations of the Apigee service of google all the rows in a bigquery table that have a certain value in a field.
this operation is quite easy to do, but when we have more than 200 lines as a result, problems arise.
The problem is that using the integration to connect to BigQuery I am not returning any listEntitiesPageToken value and not even any listEntitiesNextPageToken value
so i can't figure out how i can go about navigating the result pages
Has anyone had the same problem? What do you suggest?
In the tutorial: "https://cloud.google.com/apigee/docs/api-platform/integration/connectors-task#configure-the-connectors-task" is write : "For example, if you are expecting 1000 records in your result set, you can set the listEntitiesPageSize to 100. So when the Connectors task runs for the first time, it returns the first 100 records, the next 100 records in the second run and so on."
And there is a tip: "Use the listEntitiesPageSize parameter in conjunction with the listEntitiesPageToken parameter to navigate through the pages."
I used the tutorial to understand how to use the task for loop and I understood that I should create a "subintegration" which must be called by a "main integration" for each element present in a list / array.
But what what can i do since these tokens are empty?
How to handle the remove flight booking in webtours? It came to my mind that if I wanna run the test with 3 virtual users and how they supposed to delete the booking if the information down here (refer below) are unique for each virtual user? Does any of these variables below need to be parameterized or need to apply correlation?
If there are multiple flight id to be deleted, we can create a CSV file having those ids
and use a while loop controller to delete each of them.
You may refer -
https://guide.blazemeter.com/hc/en-us/articles/206733689-Using-CSV-DATA-SET-CONFIG
https://www.blazemeter.com/blog/using-while-controller-jmeter
As you said, it will differ for a different user, you can store each value from the response of each user(extract value using regex) and pass them in delete call.
reference link - https://guide.blazemeter.com/hc/en-us/articles/207421325-Using-RegEx-Regular-Expression-Extractor-with-JMeter-Using-RegEx-(Regular-Expression-Extractor)-with-JMeter
I don't know what "webtours" is, however there is one "golden" rule: each and every parameter which is dynamic needs to be correlated.
If you don't have any idea regarding which ones are dynamic - record the same action one more time using JMeter's HTTP(S) Test Script Recorder and compare the generated requests, parameter values (or even names) which differ needs to be correlated.
Another approach is to inspect the previous response(s) using View Results Tree listener and look if the data is present there
Check out Advanced Load Testing Scenarios with JMeter: Part 1 - Correlations article for more information and example implementation
Good evening!
At this moment I'm working on page in the Oracle Apex Application, which works the following way. This is the page, which contains some kind of big and complex report with data differentiated by one feature (let it be named feature A). On the left side of the page there is a "catalog menu", due to which user can see the data answering to feature A, on the right side the data is shown and above there is a the search bar, which can help users to find some exact data by other features feature B, feature C etc.
I had a view (let it be named V_REPORT_BIG_DATA) for showing the report, but it was so big and was loading so slow, that I've decided to switch the page on the table with the same fields as V_REPORT_BIG_DATA (let it be named T_REPORT_BIG_DATA_TEMP). Besides, it has the additional field for process identificator (let it be named PID) and is temporary not physically, but by its purpose. I thought that it must work this way: user enters the page, receives his own PID relevant to the session (it works if PID is null, otherwise it doesn't change), and then the procedure (P_REPORT_BIG_DATA_RELOAD) makes the deleting of the "old" data and uploading of the "new" one, besides these actions are executed with the one PID and are concerned to definite (say, current) user.
But my idea didn't appear to work correct. The procedure P_REPORT_BIG_DATA_RELOAD itself works fine and is executed from the Process page, and PID is a global Application Item (it is generated from a database sequence). But my brain has nearly been blown up when I saw that my table has duplicates of data concerned to one user and one PID! By making the table of logs (which has been filled with the facts, how much rows had been deleted and inserted again, in the code of P_REPORT_BIG_DATA_RELOAD) I saw very strange thing: some users "loaded" duplicates as if the uploading procedure had been executed several times simultaneously!
Taking into account all I've said before, I have the following question: what do I do wrong? What should I do, so that I wouldn't have to use the word "distinct" in the query from the table T_REPORT_BIG_DATA_TEMP?
UPD: Additional facts to my question. Excuse me for my inattention, because I thought that there I cannot edit my first posts. :-/
Well, I'll explain my problem further. :) Firstly, I did all the best for my view P_REPORT_BIG_DATA_RELOAD to expect its loading much faster, but it involves many-many rows. Secondly, the code executed from the Process Page (say, during the loading of my page) is this:
begin
if :PID is null then
:PID := NEW_PID;
end if;
P_REPORT_BIG_DATA_RELOAD(AUTH => :SUSER, PID => :PID);
end;
NEW_PID is a function which generates new PID, and P_REPORT_BIG_DATA_RELOAD is my procedure which refresh the data depending on user and his PID.
and the code of my procedure is this:
procedure P_REPORT_BIG_DATA_RELOAD
(AUTH in varchar2, PID in number)
is
NCOUNT_DELETED number;
NCOUNT_INSERTED number;
begin
--first of all I check that both parameters are not null - let me omit this part
--I find the count of data to be deleted (for debug only)
select count(*)
into NCOUNT_DELETED
from T_REPORT_BIG_DATA_TEMP T
where T.AUTHID = AUTH
and T.PID = P_REPORT_BIG_DATA_RELOAD.PID;
--I delete "old" data
delete from T_REPORT_BIG_DATA_TEMP T
where T.AUTHID = AUTH
and T.PID = P_REPORT_BIG_DATA_RELOAD.PID;
--I upload "new" one
insert into T_REPORT_BIG_DATA_TEMP
select V.*, PID from
(select S.* from V_REPORT_BIG_DATA S
where S.AUTHID = AUTH);
--I find the count of uploaded data (for debug only)
NCOUNT_INSERTED := SQL%ROWCOUNT;
--I write the logs (for debug only)
insert into T_REPORT_BIG_DATA_TEMP_LG(AUTHID,PID,INS_CNT,DLD_CNT,WHEN)
values(AUTH,PID,NCOUNT_INSERTED,NCOUNT_DELETED,sysdate);
end P_REPORT_BIG_DATA_RELOAD;
And one more fact: I tried to turn :PID into Page Item, but it cleared after every refresh in spite of that the option Maintain session state is Per session, so that I couldn't even hope for using the same PID by every definite user in definite session.
I have a problem creating sql dynamic action in oracle apex v4.2. I have two fields, Department number and department name. Department number is a text field with autocomplete. The department name is a display field. On changing the department number, the department name should be displayed by an sql query.
I created a set value dynamic action on department number, giving the correct values in page item to submit and the correct sql query referencing P3_DEPARTMENT_NO.
When i run the page, after select a department number, the department name is not coming up automatically.
Could you please suggest on what i might be missing.
Thanks in advance.
You can try use this way:
First step: In the Shared Components -> Application Processes: create a process myProcess an put your sql dynamic in.
Second step: Create a javascript function myFunction to call the process myProcess.
Third step: Use onChange event to call your javascript function myFunction.
Also you can find a lot of exemples on Denes Kubicek app: https://apex.oracle.com/pls/otn/f?p=31517:101:116042570427567.
Best regards,
iulian
The exact behaviour of autocomplete lists is probably browser dependent, but generally speaking, don't rely on the "Change" event, as it won't necessarily fire when you select from the list.
You'll need to experiment to get the behaviour you want in your particular situation, but as a starting point you might want to try replacing the "Change" event type on your dynamic action with "Lose focus". That way the dynamic action should always be triggered when you tab or click away from P3_DEPARTMENT_NO.
In similar situations in the past, I've used "Key release" instead of "Lose focus", and I've created a second dynamic action which does the same thing, but triggered by "Get focus". That combination ensures that the display field stays synchronised with the user's selection, whether a value is keyed in or selected from the autocomplete list. Whether or not you go this route depends on how happy you are about the database being hit with your department name query every time a user interacts with P3_DEPARTMENT_NO in any way.
I am a developer on a web app that uses an Oracle database. However, often the UI will trigger database operations that take a while to process. As a result, the client would like a progress bar when these situations occur.
I recently discovered that I can query V$SESSION_LONGOPS from a second connection, and this is great, but it only works on operations that take longer than 6 seconds. This means that I can't update the progress bar in the UI until 6 seconds has passed.
I've done research on wait times in V$SESSION but as far as I've seen, that doesn't include the waiting for the query.
Is there a way to get the progress of the currently running query of a session? Or should I just hide the progress bar until 6 seconds has passed?
Are these operations Pl/SQL calls or just long-running SQL?
With PL/SQL operations we can write messages with SET_SESSION_LONGOPS() in the DBMS_APPLICATION_INFO package. We can monitor these messages in V$SESSION_LONGOPS. Find out more.
For this to work you need to be able to quantify the operation in units of work. These must be iterations of something concrete, and numeric not time. So if the operation is insert 10000 rows you could split that up into 10 batches. The totalwork parameter is the number of batches (i.e. 10) and you call SET_SESSION_LONGOPS() after every 1000 rows to increment the sofar parameter. This will allow you to render a thermometer of ten blocks.
These messages are session-based but there's no automatic way of distinguishing the current message from previous messages from the same session & SID. However if you assign a UID to the context parameter you can then use that value to filter the view.
This won't work for a single long running query, because there's no way for us to divide it into chunks.
i found this very usefull
dbms_session.set_module("MY Program" , "Kicking off ... ")
..
dbms_session.set_action("Extracting data ... ")
..
dbms_session.set_action("Transforming data ... ")
..
you can monitor the progress using
select module , action from v$session where sid = :yoursessionid
I've done quite a lot of web development with Oracle over the years and found that most users prefer an indeterminate progress bar, than a determinate bar that is inaccurate (a la pretty much any of Microsoft's progress bars which annoy me no end), and unfortunately there is no infallible way of accurately determining query progress.
Whilst your research into the long ops capability is admirable and would definitely help to make the progress of the database query more reliable, it can't take into account the myriad of other variables that may/will affect the web operation's transactional progress (network load, database load, application server load, client-side data parsing, the user clicking on a submit button 1,000 times, etc and so on).
I'd stick to the indeterminate progress method using Javascript callbacks. It's much easier to implement and it will manage your user's expectations as appropriate.
Using V$_SESSION_LONGOPS requires to set TIMED_STATISTICS=true or SQL_TRACE=true. Your database schema must be granted the ALTER SESSION system privilege to do so.
I once tried using V$_SESSION_LONGOPS with a complex and long running query. But it turned up that V$_SESSION_LONGOPS may show the progress of parts of the query like full table scans, join operations, and the like.
See also: http://www.dba-oracle.com/t_v_dollar_session_longops.htm
What you can do is just to show the user "the query is still running". I implemented a <DIV> nested into a <TD> that gets longer with every status request sent by the browser. Status requests are initiated by window.SetTimeout (every 3 seconds) and are AJAX calls to a server-side procedure. The status report returned by the server-side procedure simply says "we are still running". The progress bar's width (i.e. the <DIV>'s width) increments by 5% of the <TD>s width every time and is reset to 5% after showing 100%.
For long running queries you might track the time they took in a separate table, possibly with individual entries for varying where clauses. You could use this to display the average time plus the time that just elapsed in the client-side dialog.
If you have a long running PL/SQL procedure or the like on the server side doing several steps, try this:
create a table for status messages
use a unique key for any process the user starts. Suggestion: client side's javascript date in milliseconds + session ID.
in case the long running procedure is to be started by a link in a browser window, create a job using DBMS_JOB.SUBMIT to run the procedure instead of running the procedure directly
write a short procedure that updates the status table, using PRAGMA AUTONOMOUS_TRANSACTION. This pragma allows you to commit updates to the status table without committing your main procedure's updates. Each major step of your main procedure should have an entry of its own in this status table.
write a procedure to query the status table to be called by the browser
write a procedure that is called by an AJAX call if the use clicks "Cancel" or closes the window
write a procedure that is called by the main procedure after completion of each step: it queries the status table and raises an exception with an number in the 20,000s if the cancel flag was set or the browser did not query the status for, say, 60 seconds. In the main procedure's exception handler look for this error, do a rollback, and update the status table.