I am having a little challenge.
In the attached sample data you can see that for a single AMI two different Product names exist.I do know that when that occurs only Linux/UNIX is correct. I would like to create a new column that will be looking for each AMI if it has 2 distinct string values then the new column to always be Linux/UNIX.
İmage
For the time being, i am using in power query text.contains and i specify manually those AMIs but this is not so productive. I am not aware if i can run loops with power query.
Thanks in advance for your help.
Filippos
Group the data on Ami and count Product names; merge results back into table; add custom column that checks the new column like =if [newcolumn] >1 then "Linux" else null
Another possibility. Sort table. Click to select product and type column then right click remove duplicates, which should only keep first instance. If you sorted correctly, then all the non Linuxes will be removed
I use Oracle Apex, I want that my 'display only field' is updated automatically. Well, when I use dynamic actions like this select 5 * price from ... or, for instance, random values, it works absolutely correctly, the field is filled with the value 5 * price (or set new random value). But when I use select :P4_COUNT * price from, the filed is empty. I think that the problem in :P4_COUNT (it is a number field) but I do not know what to do.
In the Dynamic Action, look for "Items to Submit" (usually under the SQL or PL/SQL code). Put the names of items that need to be submitted to session state prior to running the code. Also, note that currently, all values in session state are strings. So it's probably best to use to_number if you need a number.
Hi folks I have a question regarding calculating the value in a column in oracle.
So I have this table
NAME PROCESS1 PROCESS2 WEIGHT TOTAL_WEIGHT
ITEM1 0 0 10
ITEM2 1 1 10
ITEM3 1 1 15
So what I am trying to do here is generating the value in total_weight based on process1 and process2 in PL/SQL. Because later on I need to show the sum of total weight in PHP page. so for item 2 the total weight should be 20 and for item 3 it should be 30. Should I use procedure for generating the value in total weight? I want the value is updated when user change the value in Process1 or process2. Please help me I am kinda newbie here.
select name, process1, process2, weight, (process1+process2)*weight total_weight
from table
I see no reason that PL/SQL has to play a role in this, unless I misunderstood the requirement.
Declaring VIRTUAL (Computed) COLUMNS in Oracle Table Design
I'll agree with most of what has been said so far with some additional elaboration. My starting table design looks similar but it too is also inaccurate for some use cases as explained below.
CREATE TABLE "PROCESSED_PRODUCT_WEIGHT" (
"PRODUCT_NAME" VARCHAR2(40) NOT NULL,
"PROCESS1" NUMBER,
"PROCESS2" NUMBER,
"WEIGHT" NUMBER,
"TOTAL_WEIGHT" NUMBER GENERATED ALWAYS AS
((PROCESS1 + PROCESS2)*WEIGHT) VIRTUAL,
"RECORDED_DATE" DATE,
CONSTRAINT "PROCESSED_PRODUCT_WEIGHT_PK"
PRIMARY KEY ("PRODUCT_NAME", "RECORDED_DATE")
)
/
Previous Suggestions and Assumptions
Table Bound Attribute Properties: The table construct used by #Bob Jarvis is also known as a VIRTUAL COLUMN. It works well because the definition of TOTAL_WEIGHT is entirely dependent on other values contained within the same table.
SQL Query Associated Calculation: On the other hand, #Nishanthi Grashia and #OldProgrammer both recommend modifying the value within each SQL query executed against the database.
BOTH Cases may work assuming that the mass per unit of the product does not change during the lifetime of the production cycle.
An example where this assumption is not flexible is if the products consist of units of varying mass per unit volume.
Since it was not mentioned in the OP, consider this possibility:
Products ITEM1, ITEM2 and ITEM3 have variable weights per unit.
They are all produced in a coffee packaging plant.
Each item can be a type of coffee bean and its source.
"Processes" could be bean "treatments" such as decaffeination, roasting type or flavor infusion.
The "units" could be packaging of varying sizes. This would mean that package volumes would have a direct effect on the mass (called "weight") per product unit counted.
Test Cases for Identifying the Effect of Changing Unit Sizes
Each test case shows how a virtual column does not satisfy the possibility of variations in the unit sizes and masses of each product over time.
Test Case One:
For production observations made 2/14/2015
Test Case Two:
The mass per unit processed on 3/14/2014 is increased only, skewing the total mass produced since the item quantities made previously are multiplied by a larger value through the virtual column definition.
Test Case Three:
Data Output and Results
Above are the test results associated with all three test cases. the resulting values are not correct for the use cases created. They demonstrate that for a changing weight value, the virtual/calculated column formula and approach gives incorrect results.
A Discussion of Alternate Solutions
The trigger approach may work for maintaining calculated values for TOTAL_WEIGHT. Incremental changes (updates) are appended to the current, existing value as each component varies.
Force all DML through a single DML operation contained in a CRUD package. The problem with defining an embedded SQL statement to enforce requirements is that other processes and their developers will need to be familiar with what your isolated PHP form/page does within your app in order to duplicate it for their own operation.
If there is a concern about overhead or possible locking of the main table, then consider introducing a composite key: PRODUCT_NAME + WEIGHT. This covers for the problem so that quantities of the same product name are multiplied by their correct weight and values already calculated remain unchanged even if the weight multiplier is modified.
SOMETIMES, ALWAYS, NEVER... Are popular assumptions thrown around in developer's project circles. How likely is this to happen at all? It depends... if you're a coffee bean packaging outfit, I'd say it's quite possible.
Onward!
From what I understand, you want the field TOTAL_WEIGHT to be updated whenever the value in process 1 or process2 changes. So, Ideally you must be using TRIGGERS for this.
TRIGGERS are used to trigger an action based on an initial event.
So, for your case, the initial event is "Value change of process1 or process2" and the action expected is "automatic update of total weight field based on changed value."
But, for your requirement, a trigger is unnecessary and a totally unnecessary overhead. So, instead of having an additional field in the table, rather use a select query as below, which would calculate the value during run-time and display the real-time value.
SELECT NAME,
PROCESS1,
PROCESS2,
WEIGHT ,
(WEIGHT * (PROCESS1 + PROCESS2)) AS TOTAL_WEIGHT
FROM MY_TABLE
The output would be:
NAME | PROCESS1 | PROCESS2 | WEIGHT | TOTAL_WEIGHT
------------------------------------------------------------
ITEM1 | 0 | 0 | 10 | 0
ITEM2 | 1 | 1 | 10 | 20
ITEM3 | 1 | 1 | 15 | 30
You can use this TOTAL_WEIGHT using something like resultSet.getLong("TOTAL_WEIGHT");
Or, if you are very particular in having the field, then you can modify your update query to include
UPDATE MY_TABLE SET FIELD1=VALUE1, FIELD2=VALUE2, ... ,
TOTAL_WEIGHT = (WEIGHT * (PROCESS1 + PROCESS2))
WHERE SOME_CONDITION;
If you're using 11g or later, the safest way to handle this would be to make TOTAL_WEIGHT a computed column. The CREATE TABLE statement would then become something like
CREATE TABLE MY_TABLE
(PROCESS1 NUMBER,
PROCESS2 NUMBER,
WEIGHT NUMBER,
TOTAL_WEIGHT NUMBER GENERATED ALWAYS AS (NVL((PROCESS1+PROCESS2)*WEIGHT, 0)));
Done this way applications don't need to know how to compute TOTAL_WEIGHT - it's always done correctly.
SQLFiddle here.
Share and enjoy.
I would like to knew how can I find the maximum value in column in JDE Solution? Would you mind to show me the way to do it? Because I am not able to do it by using JDE RDA.
What do you mean by:
..i not able to do it by using JDE RDA..
You don't know how to use it or you're using the FDA?
Well, in RDA you can use the Aggregate Maximum Of, doing a Level Break on the column you want the maximum value.
On FDA you need to code your logic, something like:
MaxValue = 0
Begin Loop through the table
If table.column_you_want > MaxValue
MaxValue = table.column_you_want
End If
End Loop
Depending on your needs, if you are looking to find the next available ID to use in your table, there is already a concept well implemented in JDE to keep track of the next unique id for a table or even a process.
Unique id for a table
Look at the program P00022 which hold a next number by table. There is the business function X00022 you can use in your report to retrieve the value.
Unique ID for a process
Look at the program P0002 which holds next numbers by modules for specific document type. Use the business function X0002 to access the values in your RDA.
My company database has 20 different string formats for their primary product label. All 20 of them are stored in a separate look-up table
1 are strings starting with 'W'
2 are strings starting with 'TAIC'
3 are strings starting with 'D'
...
Next to the label attribute is the 'type' attribute, which stores the number related to which prefix the label contains.
I'm tasked with updating one of our modules for better runtime. One of the queries I ran across deals with all labels containing 'TAIC' as the prefix. However, instead of comparing whether the type number is equal to 2, it runs a LIKE operation checking for each label that begins with TAIC.
Now, my question is this -- since my goal is for better run time, would it be wise to switch from the like operator to just a regular equality operation against the type attribute? It seems that running a regular expression-ish operation against a string would be a bit more time consuming, but enough to significantly alter the run time of a system?
In Oracle, both these operations:
SELECT *
FROM mytable
WHERE pk LIKE 'TAIC%'
and
SELECT *
FROM mytable
WHERE type = 2
are sargable, that is able to use an index on the appropriate fields.
The numeric index, however, would be more compact and hence require less time to traverse, so using numeric comparison could increase the query performance.