- I now actually prefer defining all the necessary variables in the script - that way I can be sure that I can delete all the variables in the variable_manager and be sure that all the necessary ones will be re-created and only the non_necessary ones are gone.
- For variables that are populated on the GUI, there is the syntax (for example) >> SET v_myvar = = Getfieldselections(date); <<
- In my current app there are several blocks in the script, each one with a condition for the execution, a variable > v_database_action <
- In one specific block (where $(v_database_action)=6 ) I have to do a RESIDENT LOAD from one other table (that is also loaded in that block) with a WHERE condition specifying that one specific field in the table be equal to that variable.
- That variable, though initiated in the script, has in the meantime (through some other action by the user) been filled with a value (and that SET command is set to NOT be executed when $(v_database_action)=6, so that it isn't reset.
<=> Still, that WHERE condition fails and when I load without it and I load the value of that variable is exactly that formula, not its output.
The same happens when I define that variable on the GUI. The script, when reloading with $(v_database_action)=6, uses the formula, not the output. Thus of course it cannot find any matching records.
Is there any way around this other than asking the user on the GUI to actually type the nr of the record they want to edit?
Your fields all have the same number of subfield items and you want in your output table the subfield items aligned, that is only records with first item of field1, first item field2, first item field3 etc.
Maybe like this:
LOAD *
where ID2 = (RowNo() *F1*F2 + RowNo()*F3 + RowNo()+1);
I will take a while to understand what this code is doing. There is some mathematics behind it, of course. I had a similar solution to the cartesian product when many-joining two tables, but this is different.
Let's see. I'll keep you posted.
P.S.: Okay, it seems to do exactly what it is supposed to.
I guess if i were to add one more field to that - I do have one more actually, I just omitted it in my question - I will have to somehow adapt that logic? I haven't understood it yet, so I cannot tell how.
Would you mind explaining the logic behind your code?
Don't get confused with the different fields F1,F2,F3,F4. Since this approach only really works with fields having same number of subitems, all 4 numbers are equal (and can be replaced by using just one of them).
I have now removed F2, F3 and F4 (renamed them all to F1)´, but I still don't understand. I'm not much of a mathematician. My uncle was, but I clearly did not inherit this - for which I am thankful in other ways 😉
Would you mind helping me understand this?
So, if I assume that I have 10 elements, then
- when rowNo() is 1 (in record #1), that means ID2 = 1*10*10 + 1*10*10 + 1*10 + 1+1 = 212
- when rowNo() is 2 (in record #2), it means ID2 = 2*10*10 + 2*10*10 + 2*10 + 2+1 = 423
- when rowNo() is 3 (in record #3) it means ID2 = 3*10*10 + 3*10*10 + 3*10 + 3 + 1 = 634
OK, so it always adds 211, starting at 212 - but why?
I would have thought that with 10*10*10*10 = 10.000 records, then every 1000th record, everything would be new, so I'd load records 1, 1001, 2002, 3003 etc.
There seems to be an error in the logic, too - the table (with 14 items) still has 95 lines - but some items seem to be there several times, so I have to clear that up before I can tell you what exactly the problem is.
Thanks a lot!
Best regards,
DataNibbler
P.S.: Okay, there are 13 different sub_items in that item. But 13*13 is not 95, so I'm not quite sure what is wrong.
Yes, your filter needs to adapt to your number of fields and field elements. That's where somewhat complicated formula comes from.
And regarding your post earlier this day, a little hint: rowno() will not return 1, but zero when used in a where clause for the first record coming in, until there is actually a record in the output table.
I noticed there was something wrong. Now I have two LOADs - the first returns that cartesian product, but also a Line_ID, and the second RESIDENT (I try to avoid the preceding because it's harder for others to understand) then extract just the records I want - I have an inbetween step where I calculate, in a loop, which records I want to extract.
