[Bug 53851] New: Oracle CURSOR still returns : ORA-06553: PLS-306: wrong number or types of arguments in call to 'WTRK11GET_1'ORA-06553: PLS-306: wrong number or types of arguments in call to 'WTRK11G
https://issues.apache.org/bugzilla/show_bug.cgi?id=53851 Priority: P2 Bug ID: 53851 Assignee: issues@jmeter.apache.org Summary: Oracle CURSOR still returns : ORA-06553: PLS-306: wrong number or types of arguments in call to 'WTRK11GET_1'ORA-06553: PLS-306: wrong number or types of arguments in call to 'WTRK11GET_1' Severity: blocker Classification: Unclassified OS: Windows XP Reporter: rudi.ch...@otda.ny.gov Hardware: PC Status: NEW Version: 2.7 Component: Main Product: JMeter ORA-06553: PLS-306: wrong number or types of arguments in call to 'WTRK11GET_1' here is the request in the Tree Results screen [Callable Statement] call WTRK_PACKAGE.WTRK11GET_1(?,?,?) AX44189C,0,0 VARCHAR,INTEGER,INTEGER (Note : I put INTEGER out opf the suggestion from the BUG that was declared fixed in 2008 - 4657 I also tried other variations including OUT , etc) here is the procedure def in Oracle: PROCEDURE WTRK11GET_1 (P_WTRK_CIN_IN_VCIN_ID IN VARCHAR2, P_STATUS_OUT OUT NUMBER, p_recordset OUT refcursor); The JDBC driver class used in the JDBC connection oracle.jdbc.driver.OracleDriver See also attachments screenshots. Any ides how I can solve this. I don't really need at this point the CURSOR value, just need to be able to run this as performance test. Thanks, Rudi -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53851] Oracle CURSOR still returns : ORA-06553: PLS-306: wrong number or types of arguments in call to 'WTRK11GET_1'ORA-06553: PLS-306: wrong number or types of arguments in call to 'WTRK11GET_1'
https://issues.apache.org/bugzilla/show_bug.cgi?id=53851 Sebb s...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID Severity|blocker |normal --- Comment #1 from Sebb s...@apache.org --- It looks like the 3rd parameter is not an INTEGER, so the error message is correct. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53851] Oracle CURSOR still returns : ORA-06553: PLS-306: wrong number or types of arguments in call to 'WTRK11GET_1'ORA-06553: PLS-306: wrong number or types of arguments in call to 'WTRK11GET_1'
https://issues.apache.org/bugzilla/show_bug.cgi?id=53851 Sebb s...@apache.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #3 from Sebb s...@apache.org --- For help with using JMeter, in the first instance please read the manual. If you cannot find the answer there, please subscribe to the JMeter user list and post there. Bugzilla is not a support forum. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53855] New: A CSV EOF condition is not interpreted as Boolean False by the While-controller
https://issues.apache.org/bugzilla/show_bug.cgi?id=53855
Priority: P2
Bug ID: 53855
Assignee: issues@jmeter.apache.org
Summary: A CSV EOF condition is not interpreted as Boolean
False by the While-controller
Severity: normal
Classification: Unclassified
OS: All
Reporter: mi+apa...@aldan.algebra.com
Hardware: PC
Status: NEW
Version: 2.7
Component: Main
Product: JMeter
Created attachment 29356
-- https://issues.apache.org/bugzilla/attachment.cgi?id=29356action=edit
An illustrating test-case
When CSV Data set is reading a CSV-file, upon reaching reaching EOF, all of the
specified variables are set to EOF (the exact string representation is
controlled by the csvdataset.eofstring property).
Unfortunately, simply using one of the variables as a While-controller's
condition is impossible -- apparently, the EOF is still interpreted as
True.
There are examples and code-snippets online, where a simple CSV-set variable is
used to control a While-controller, so it was/is possible to do on some earlier
releases or some Operating Systems (at least one online posting, for example,
mentions it working on properly on Windows, but not on Linux). Instead of
simply using
${column1}
as a while-controller's condition, one must use something as unwieldy (and
unportable) as:
${__jexl(${column1} != EOF)}
It would seem, the Boolean representation of EOF ought to be False regardless
of its String representation.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53856] New: While-contoller's seems to check the condition at the end, rather than beginning of the loop
https://issues.apache.org/bugzilla/show_bug.cgi?id=53856 Priority: P2 Bug ID: 53856 Assignee: issues@jmeter.apache.org Summary: While-contoller's seems to check the condition at the end, rather than beginning of the loop Severity: normal Classification: Unclassified OS: All Reporter: mi+apa...@aldan.algebra.com Hardware: All Status: NEW Version: 2.7 Component: Main Product: JMeter Created attachment 29358 -- https://issues.apache.org/bugzilla/attachment.cgi?id=29358action=edit Illustrating sample As illustrated by the attached sample, the While-controller may enter the loop one last time even when the specified condition is false. In my example, the loop goes through a CSV-file with three lines invoking a Debug Sampler. However, the Debug Sampler is shown in the results tree not three times, but four -- in the last, fourth, invocation all variables are set EOF. The work-around is to put an If-controller inside the loop and hang everything off of it. This should not be necessary. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53856] While-contoller's seems to check the condition at the end, rather than beginning of the loop
https://issues.apache.org/bugzilla/show_bug.cgi?id=53856 --- Comment #1 from Mikhail T. mi+apa...@aldan.algebra.com --- Created attachment 29359 -- https://issues.apache.org/bugzilla/attachment.cgi?id=29359action=edit Sample CSV-file refered to by the sample test-plan -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53855] A CSV EOF condition is not interpreted as Boolean False by the While-controller
https://issues.apache.org/bugzilla/show_bug.cgi?id=53855 --- Comment #1 from Mikhail T. mi+apa...@aldan.algebra.com --- Created attachment 29360 -- https://issues.apache.org/bugzilla/attachment.cgi?id=29360action=edit Sample CSV-file refered to by the sample test-plan -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53857] New: Save-button should be disabled (greyed out), if no changes were made since the last save
https://issues.apache.org/bugzilla/show_bug.cgi?id=53857 Priority: P2 Bug ID: 53857 Assignee: issues@jmeter.apache.org Summary: Save-button should be disabled (greyed out), if no changes were made since the last save Severity: enhancement Classification: Unclassified OS: FreeBSD Reporter: mi+apa...@aldan.algebra.com Hardware: PC Status: NEW Version: 2.7 Component: Main Product: JMeter Subject says it all, really... By accepted standard of the GUIs, the Save button (the one still showing the 3 diskette no one uses any longer :-) should be disabled, when the most recently saved version is still current. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53855] A CSV EOF condition is not interpreted as Boolean False by the While-controller
https://issues.apache.org/bugzilla/show_bug.cgi?id=53855 Sebb s...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Sebb s...@apache.org --- The While Controller is documented as looping until the condition matches false. Changing this to also match EOF would potentially break some scripts. As a work-round, you can use: csvdataset.eofstring=false -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53856] While-contoller's seems to check the condition at the end, rather than beginning of the loop
https://issues.apache.org/bugzilla/show_bug.cgi?id=53856 Sebb s...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Sebb s...@apache.org --- The CSV dataset entry is only updated within the While Loop, so of course the debug sampler will show EOF before the loop exits. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53856] While-contoller's seems to check the condition at the end, rather than beginning of the loop
https://issues.apache.org/bugzilla/show_bug.cgi?id=53856 --- Comment #3 from Mikhail T. mi+apa...@aldan.algebra.com --- I am sorry, but the current behavior makes no sense. What possible use-case is there for iterating through a CSV-file, that has N rows, N+1 times? All this does is necessitates the use of an If-controller with the same condition repeated -- so as to skip the last iteration. I did some research before filing this bug-report. At least one other user -- a lot more seasoned with JMeter than myself -- sees no other way to use While-controller with the CSV Dataset. And that's a shame... -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53856] While-contoller's seems to check the condition at the end, rather than beginning of the loop
https://issues.apache.org/bugzilla/show_bug.cgi?id=53856 --- Comment #5 from Mikhail T. mi+apa...@aldan.algebra.com --- (In reply to comment #4) It's impossible to fix this, as the condition can only be checked after the CSV file entry has been read, and the CSV entry is only read if the loop is entered. What, then, happens the first time, the condition is evaluated? Before the CSV file is read at all? Note that CSV DataSet has an option to stop the thread on reaching EOF. Yes, but this is of no help, if one wants to nest While-controllers -- and does not wish an inner one to end the entire thread. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 53856] While-contoller's seems to check the condition at the end, rather than beginning of the loop
https://issues.apache.org/bugzilla/show_bug.cgi?id=53856
--- Comment #6 from Mikhail T. mi+apa...@aldan.algebra.com ---
Created attachment 29361
-- https://issues.apache.org/bugzilla/attachment.cgi?id=29361action=edit
Enhance the logging output of WhiteController's endOfLoop() method (not for
production use)
Ok, some deeper debugging -- after enhancing the log.debug messages inside
WhileController.java a little -- reveal, that the controller's condition is
checked twice per CSV-file row. The endOfLoop() method is invoked twice: first
with the loopEnd-argument set to false, and then -- to true.
At the end, when the CSV Dataset sets all variables to EOF, the function is
called one more time -- with loopEnd set to false. For brevity, I removed the
3rd row from the sample.csv:
2012/09/11 23:38:31 INFO - jmeter.threads.JMeterThread: Thread started: Thread
Group 1-1
2012/09/11 23:38:31 DEBUG - org.apache.commons.jexl.ScriptFactory: Parsing
script: ${greek} != EOF;
2012/09/11 23:38:31 DEBUG - jmeter.control.WhileController: Condition string at
loop-end true. (Called from next)
2012/09/11 23:38:31 DEBUG - jmeter.control.WhileController: Condition value:
false
2012/09/11 23:38:31 INFO - jmeter.services.FileServer: Stored: sample.csv
2012/09/11 23:38:31 DEBUG - org.apache.commons.jexl.ScriptFactory: Parsing
script: alpha != EOF;
2012/09/11 23:38:31 DEBUG - jmeter.control.WhileController: Condition string at
loop-beginning true. (Called from nextIsNull)
2012/09/11 23:38:31 DEBUG - jmeter.control.WhileController: Condition value:
false
2012/09/11 23:38:31 DEBUG - org.apache.commons.jexl.ScriptFactory: Parsing
script: alpha != EOF;
2012/09/11 23:38:31 DEBUG - jmeter.control.WhileController: Condition string at
loop-end true. (Called from next)
2012/09/11 23:38:31 DEBUG - jmeter.control.WhileController: Condition value:
false
2012/09/11 23:38:31 DEBUG - org.apache.commons.jexl.ScriptFactory: Parsing
script: beta != EOF;
2012/09/11 23:38:31 DEBUG - jmeter.control.WhileController: Condition string at
loop-beginning true. (Called from nextIsNull)
2012/09/11 23:38:31 DEBUG - jmeter.control.WhileController: Condition value:
false
2012/09/11 23:38:31 DEBUG - org.apache.commons.jexl.ScriptFactory: Parsing
script: beta != EOF;
2012/09/11 23:38:31 DEBUG - jmeter.control.WhileController: Condition string at
loop-end true. (Called from next)
2012/09/11 23:38:31 DEBUG - jmeter.control.WhileController: Condition value:
false
2012/09/11 23:38:31 DEBUG - org.apache.commons.jexl.ScriptFactory: Parsing
script: EOF != EOF;
2012/09/11 23:38:31 DEBUG - jmeter.control.WhileController: Condition string at
loop-beginning false. (Called from nextIsNull)
2012/09/11 23:38:31 DEBUG - jmeter.control.WhileController: Condition value:
true
2012/09/11 23:38:31 INFO - jmeter.threads.JMeterThread: Thread finished:
Thread Group 1-1
The above output tells me:
a. This bug report is not at all INVALID
b. It is possible to fix the problem...
--
You are receiving this mail because:
You are the assignee for the bug.
