I am analysing the siebel log and i see that every query runs twice in the log. Could anyone pls tell me why this happens?
For example the below query is one of the many queries that i found got executed twice in the log
SELECT /*+ ALL_ROWS */
T2.CONFLICT_ID,
T2.LAST_UPD,
T2.CREATED,
T2.LAST_UPD_BY,
T2.CREATED_BY,
T2.MODIFICATION_NUM,
T2.ROW_ID,
T1.BU_ID,
T2.MULTI_LINGUAL_FLG,
:1
FROM
SIEBEL.S_LST_OF_VAL_BU T1,
SIEBEL.S_LST_OF_VAL T2
WHERE
T2.ROW_ID = T1.LST_OF_VAL_ID (+) AND
(T2.TYPE = :2 AND T2.NAME = :3)
ORDER BY
T2.TYPE, T2.ORDER_BY, T2.VAL
The query should NOT run twice, unless the logged in user has repeated an operation, and the Business Component is not cached. You will see the SQLs for LOV values repeated in the log, but the value of bind variable ":2" will be different each time. You can see these values just under the SQL
eg: Bind variable 2: TIME_ZONE_DST_ORDINAL
Bind variable 2: DAY_NAME
Is there any other SQL which is repeated and not for the S_LST_OF_VAL tables ?
Related
I'm getting an unexpected result when I use an IF in the RETURN clause of a DAX expression. If I don't use the IF, but instead just a variable, then the result is ok.
I've created a test scenario to explain my problem:
I have two test tables:
Table: "Test Object"
Table: "Test Group"
These have a unidirectional relation on "Group code"
I have created a measure "Test measure":
This gives the correct result:
I have set a page filter to only show Group Code "G01".
This all works ok up to this point.
But it goes wrong when I use an IF function:
I then get the following (incorrect) result. Apparently the relation and/or page filter seems to be ignored now:
NB: The result is the same regardless of from which table I use the "Group code" field.
What am I missing here?
I've created a PBIX file that shows the problem:
https://www.dropbox.com/s/76ld1kv503ul6nm/DAX%20problem%20with%20IF.pbix?dl=0
This is called "Auto-Exist" in PBI:
https://www.sqlbi.com/articles/understanding-dax-auto-exist/
If you look closer to the results, you'll notice that your report shows all possible combinations between Group Codes and Object Codes.
This is happening whenever you use a combination of fields from the different tables in a report: PBI first creates a cross-join between these fields, and then eliminates those combinations that result in blanks, so you only see meaningful combinations.
However, you IF statement overrides this logic - you are returning a result always, even if a combination is blank (Blank < 40 test returns "low end" because blank is treated as zero).
To fix it, calculate results only if the variable is not blank, i.e:
Price category =
var lowestPrice = MIN(Object[Price])
var result = IF( NOT ISBLANK(lowestPrice), IF(lowestPrice < 40, "Low end", "High end"))
Return result
You will get:
P.S. Page filter is irrelevant here, it simply filters the table after it's calculated.
Today I was just bitten in the rear end by something I didn't expect. Here's a little script to reproduce the issue:
create temporary table aaa_state(id int, amount int);
create temporary table aaa_changes(id int, delta int);
insert into aaa_state(id, amount) values (1, 0);
insert into aaa_changes(id, delta) values (1, 5), (1, 7);
update aaa_changes c join aaa_state s on (c.id=s.id) set s.amount=s.amount+c.delta;
select * from aaa_state;
The final result in the aaa_state table is:
ID
Amount
1
5
Whereas I would expect it to be:
ID
Amount
1
12
What gives? I checked the docs but cannot find anything that would hint at this behavior. Is this a bug that I should report, or is this by design?
The behavior you are seeing is consistent with two updates happening on the aaa_state table. One update is assigning the amount to 7, and then this amount is being clobbered by the second update, which sets to 5. This could be explained by MySQL using a snapshot of the aaa_state table to fetch the amount for each step of the update. If true, the actual steps would look something like this:
1. join the two tables
2. update the amount using the "first" row from the changes table.
now the cached result for the amount is 7, but this value will not actually
be written out to the underlying table until AFTER the entire update
3. update the amount using the "second" row from the changes table.
now the cached amount is 5
5. the update is over, write 5 out for the actual amount
Your syntax is not really correct for what you want to do. You should be using something like the following:
UPDATE aaa_state as
INNER JOIN
(
SELECT id, SUM(delta) AS delta_sum
FROM aaa_changes
GROUP BY id
) ac
ON ac.id = as.id
SET
as.amount = as.amount + ac.delta_sum;
Here we are doing a proper aggregation of the delta values for each id in a separate bona-fide subquery. This means that the delta sums will be properly computed and materialized in the subquery before MySQL does the join, to update the first table.
I have found a very weird behaviour in our Siebel 7.8 application. This is part of a business service:
var bo:BusObject;
var bc:BusComp;
try {
bo = TheApplication().GetBusObject("Service Request");
bc = bo.GetBusComp("Action");
bc.InvokeMethod("SetAdminMode", "TRUE");
bc.SetViewMode(AllView);
bc.ClearToQuery();
bc.SetSearchSpec("Status", "='Unscheduled' OR ='Scheduled' OR ='02'");
bc.ExecuteQuery(ForwardOnly);
var isRecord = bc.FirstRecord();
while (isRecord) {
log("Processing activity '" + bc.GetFieldValue("Id") + "'");
bc.SetFieldValue("Status", "03");
bc.WriteRecord();
isRecord = bc.NextRecord();
}
} catch (e) {
log("Exception: " + e.message);
} finally {
bc = null;
bo = null;
}
In the log file, we get something like this:
Processing activity '1-23456'
Processing activity '1-56789'
Processing activity '1-ABCDE'
Processing activity '1-ABCDE'
Exception: The selected record has been modified by another user since it was retrieved.
Please continue. (SBL-DAT-00523)
So, basically, it processes a few records from the BC and then, apparently at random, it "gets stuck". It's like the NextRecord call isn't executed, and instead it processes the same record again.
If I remove the SetFieldValue and WriteRecord to avoid the SBL-DAT-00523 error, it still shows some activities twice (only twice) in the log file.
What could be causing this behaviour?
It looks like in business component "Action" you have join(s) that can return multiple records for one base record and you use ForwardOnly mode to query BC.
Assume, for example, in table S_EVT_ACT you have one record with a custom column X_PHONE_NUMBER = '12345678' and you have two records in table S_CONTACT with column 'MAIN_PH_NUM' equal to the same value '12345678'. So when you will join these two tables using SQL like this:
SELECT T1.* FROM SIEBEL.S_EVT_ACT T1, SIEBELS_CONTACT T2
WHERE T1.X_PHONE_NUMBER = T2.MAIN_PH_NUM
as a result you will get two records, with the same T1.ROW_ID.
Exactly the same situation happens when you use ForwardOnly cursor mode in eScript, in this case Siebel just fetches everything what database has returned. And that why it's a big mistake to iterate over business component while it's queried in a ForwardOnly mode. You should use ForwardBackward mode instead, because in this case Siebel will exclude duplicates records (it also true for normal UI queries, because it also executed in ForwardBackward mode).
Actually this is the most important and less known difference between ForwardOnly and ForwardBackward cursor modes.
Try changing that query mode
bc.ExecuteQuery(ForwardOnly);
to ForwardBackward.
My Scenario:
I have a report on page 1 which has a link to page 2. This link passes an ID to page 2 (V2_ID gets set with V1_ID).
I then have two items called V2_ID and V2_NAME on page 2, as well as a PL/SQL process on page 2 which executes after the header loads which
select name into :V2_NAME from table where id = :V_ID;
The V2_ID shows the value, but the V2_NAME is always blank.
How can I pre-populate this variable. This is a very simple example as my use case is much more complicated, but the concept is the same. I can't use automatic row fetch because each item comes from a different table (it is a horrible database design, but I have to work with it).
Cheers
If on page 2 you have a PL/SQL process at the process point='On Load - After Header' and the procedure looks something like this:
Begin
select name into :V2_NAME from table where id =:V2_ID;
end;
and no condition on it then it should work.
Check that :V2_NAME does not have Source Type= Always NULL;
Correct me if Im wrong, from what ive understood, only one value is passed from page 1 to page 2 which is V1_ID to V2_ID,right?then on page 2, you have a process that will execute after the header loads and that is
SELECT name
INTO :V2_NAME
FROM TABLE
WHERE id = :V_ID
Is the :V_ID a typo?It should be :V2_ID,if its not maybe its the cause as to why :V2_NAME doesnt give you a value.
Instead of having a process after header, why dont you just put the query in the item SOURCE, choose type: QUERY, used: ALWAYS, REPLACE ANY EXISTING VALUES ON SESSION STATE.
then in the query box, put
SELECT name
FROM TABLE
WHERE id = :V2_ID
I am using Java DB (Java DB is Oracle's supported version of Apache Derby and contains the same binaries as Apache Derby. source: http://www.oracle.com/technetwork/java/javadb/overview/faqs-jsp-156714.html#1q2).
I am trying to update a column in one table, however I need to join that table with 2 other tables within the same database to get accurate results (not my design, nor my choice).
Below are my three tables, ADSID is a key linking Vehicles and Customers and ADDRESS and ZIP in Salesresp are used to link it to Customers. (Other fields left out for the sake of brevity.)
Salesresp(address, zip, prevsale)
Customers(adsid, address, zipcode)
Vehicles(adsid, selldate)
The goal is to find customers in the SalesResp table that have previously purchased a vehicle before the given date. They are identified by address and adsid in Customers and Vechiles respectively.
I have seen updates to a column with a single join and in fact asked a question about one of my own update/joins here (UPDATE with INNER JOIN). But now I need to take it that one step further and use both tables to get all the information.
I can get a multi-JOIN SELECT statement to work:
SELECT * FROM salesresp
INNER JOIN customers ON (SALESRESP.ZIP = customers.ZIPCODE) AND
(SALESRESP.ADDRESS = customers.ADDRESS)
INNER JOIN vehicles ON (Vehicles.ADSId =Customers.ADSId )
WHERE (VEHICLES.SELLDATE<'2013-09-24');
However I cannot get a multi-JOIN UPDATE statement to work.
I have attempted to try the update like this:
UPDATE salesresp SET PREVSALE = (SELECT SALESRESP.address FROM SALESRESP
WHERE SALESRESP.address IN (SELECT customers.address FROM customers
WHERE customers.adsid IN (SELECT vehicles.adsid FROM vehicles
WHERE vehicles.SELLDATE < '2013-09-24')));
And I am given this error: "Error code 30000, SQL state 21000: Scalar subquery is only allowed to return a single row".
But if I change that first "=" to a "IN" it gives me a syntax error for having encountered "IN" (Error code 30000, SQL state 42X01).
I also attempted to do more blatant inner joins, but upon attempting to execute this code I got the the same error as above: "Error code 30000, SQL state 42X01" with it complaining about my use of the "FROM" keyword.
update salesresp set prevsale = vehicles.selldate
from salesresp sr
inner join vehicles v
on sr.prevsale = v.selldate
inner join customers c
on v.adsid = c.adsid
where v.selldate < '2013-09-24';
And in a different configuration:
update salesresp
inner join customer on salesresp.address = customer.address
inner join vehicles on customer.adsid = vehicles.ADSID
set salesresp.SELLDATE = vehicles.selldate where vehicles.selldate < '2013-09-24';
Where it finds the "INNER" distasteful: Error code 30000, SQL state 42X01: Syntax error: Encountered "inner" at line 3, column 1.
What do I need to do to get this multi-join update query to work? Or is it simply not possible with this database?
Any advice is appreciated.
If I were you I would:
1) Turn off autocommit (if you haven't already)
2) Craft a select/join which returns a set of columns that identifies the record you want to update E.g. select c1, c2, ... from A join B join C... WHERE ...
3) Issue the update. E.g. update salesrep SET CX = cx where C1 = c1 AND C2 = c2 AND...
(Having an index on C1, C2, ... will boost performance)
4) Commit.
That way you don't have worry about mixing the update and the join, and doing it within a txn ensures that nothing can change the result of the join before your update goes through.