Using Orbeon to create a form, in a repeat I ran into an issue with setting Initial values. After the first iteration, the default value does not work. After some research, I found this to be a common issue, but no resolution. Need an expression that would keep track of each node that is set and account for any values that are changed from their initial value.
Thanks!
You could try using a Calculated Value (rather than an Initial Value) which sets the default value if the element is blank, but leaves it alone if it has been completed.
Ie, try something like:
if (. = '') then 'default value' else .
Related
I can't for the life of me figure out why my transform which I have setting a 'constant' value is not setting it? Anywhere I can look for details?
Here's the add header - constant step
So WHY do I not get my test value in the output??
I even tried 'set field value to constant' step which takes the one row coming from my filer step and sets it to a constant value which also produces nothing! IDK whats going on here!
Thanks for the suggestions… I actually figured this out it has to do with the fact that the text output steps have a setting to not create when the transformation first starts I had to check that box…
in PDI I've got the following structure
0_Metajob
1_Load_1
1_Load_2
1_SimpleEvaluation
1_Mail
As of now
1_Load_1 and 1_Load_2 are independent of each other. The second one will run, irrespective of the success of the first one. That is okay, I want it that way!
Issue
I want to have a counter that is incremented by one every time one of the single loads fails, i.e. in my example the counter can take the values 0, 1 or 2.
What do I need it for? Customer will receive a mail at the end of the metajob. The aforementioned value determines the subject of the mail, i.e. 0=everything fine, 1=so-so, 2=load totally failed!
Why not mailing within every single the Load-Job? I do that but without attaching the log-file because it is usually non-finished. Therefore the log-file is mailed with the mail that is sent when the Metajob is finished.
Tried
"Set a variable". Thought I can simply increment it with adding a one in the value field, i.e. "${VariableName}+1". Of course, this step is implementened within a fail path of each Load-Job.
However, it didn't work.
Would anyone mind helping me? I would appreciate that!
Set Variable doesn't do calculations, you'll need a Javascript step for that.
Fortunately, variables can be also be set within the Javascript step. This bit of code should go into each of the steps you put in place of the Set Variable steps:
var i = parseInt(parent_job.getVariable("Counter"),0);
i = i + 1;
parent_job.setVariable("Counter",i);
true;
This bit of code gets the variable "Counter" from the parent job and converts it to int, since all Pentaho variables are strings. Then it increments it and sets the job variable again. The "true" at the end is to ensure that the javascript step reports success to the main job.
IMPORTANT: This works roughly as you would expect in a Job. It will NOT in a transformation!
I have an Oracle Forms app. There is a form with a date field and I need to keep it initial value (when form is loaded), to compare it with actual value in the field. Also there is a button on the form, that posts changes.
I've tried to store initial value with global variable and check if it's changed, also I've tried to simply check that :system.record_status != 'QUERY' to track if date is modified.
Problem that at the moment, when button is pressed and post is done the values of all global variables become null, so I can't compare the initial value with the new one and :system.record_status becomes 'QUERY' again, and I don't see any more if user modified something.
How to keep the initial values or track that data was changed, doesn't matter if user posts changes or not?
This:
Problem that at the moment, when button is pressed and post is done the values of all global variables become null, so I can't compare the initial value with the new one
doesn't work that way. Post (if you refer to POST built-in) (nor COMMIT, as we're at it) doesn't clear global variables. Explicitly setting it to NULL does, so - check the form whether you've done it somewhere in your code. How? Run the form in debug mode, trace its execution and see what's going on.
Another thing that might be going wrong is that global variables's datatype is CHAR so - if you plan to compare it to a different datatype value, you should perform conversion. As it is a date value, consider applying TO_DATE function to the global variable with appropriate format mask.
this will work:
IF GET_ITEM_PROPERTY(:SYSTEM.CURSOR_ITEM,UPDATE_COLUMN) ='TRUE' THEN
Copy(Get_Item_Property(itm, Database_Value), :System.Cursor_Item);
I am trying to log all changes in variable values in a SSIS generated with BIML.
I managed to create an event handler that writes everytime a variable changes its value.
When I log I use a parameter whose value I set to "System.VariableValue". I pass this parameter (togheter with variableName and PackageName) to a StoredProc and i write in a log table.
My problem is that often (but NOT always) it seems the parameter does not has any value. I see a new line in the DB Log table so this means the evnt is correctly raised and handled BUT it seems the parameter is empty.
The strangest thing is that sometimes values are logged correctly but not always, not for the same variables, not for the same packages, rather, in a quite random fashion.
Could it be a problem the fact that several variables could change value almost at the same time (some contention on the DB) ? I doubt it, because the row itself gets written on the DB. I even tried to write, as a value, something like 'New value = ' + ? that is, appending the parameter value to a fixed string. The fixed part gets written correctly but.. no value.
The name of the variable that changed value is always written correctly.
Any idea what this could be due to?
As a workaround I tried to use the ready-made logging facility of SSIS but in this case in the message column of the SYSSSISLOG table i can just read the name of the variable that changed, not its new value.
thankx
You could use Event Handler to do that. Go to the Variables page, go to Variable Grid Options, check Raise event when variable value changes, and there should be one more option appear for those variables, which is Raise Change Event, default to False, change to True for those variables that you need to track the changes (log). And put a logging task into Event handler
UPDATE
the new line could be the value of parameter has been reset, and that value, most likely equal to blank or whitespace, but still, that is recognized as value change.
if you are not very sure when that happened, you could set a Breakpoint to certain task and add watch window to see how the value change or whether the value will hit blank in the middle of your process
As I rarely loop into a field symbol, I often forget to use ASSIGNING instead of INTO which will promptly cause an abend. Is there a valid use of INTO with <fieldsymbol> or is this something that the syntax checker really ought to catch?
LOOP...INTO is perfectly valid but it will work differently. LOOP...INTO transports the values to the structure provided but ASSIGNING assigns the field symbol to the actual table rows.
The only difference is if you are going to change the table contents. See the following:
* Changes all entries in the CARRID column of lt_flights to 50.
LOOP AT lt_flights ASSIGNING <flight>.
<flight>-carrid = 50.
ENDLOOP.
* Does not change the entries in lt_flights (MODIFY...FROM would be required).
ASSIGN <flight> TO ls_flight.
LOOP AT lt_flights INTO <flight>.
<flight>-carrid = 50.
ENDLOOP.
LOOP...INTO with a field symbol would be useless unless you had some kind of dynamic programming requirement.
It is valid when <fieldsymbol> was previously assigned to a structure which has the type of the lines of the table you loop over.
It is a perfectly valid statement:
APPEND INITIAL LINE TO lt_foo ASSIGNING <ls_foo>.
READ TABLE lt_bar INTO <ls_foo> INDEX 1.
A field symbol just takes the place of a variable - at almost any point - so the syntax check can't flag this as invalid. It might issue a warning, though...