GeezerVison is showing github.com — "Call params for test are not valid" for all tests in specific schema · Issue #885 · utPLSQL/utPLSQL
"Call params for test are not valid" for all tests in specific schema #885DescriptionDescribe the bug
The error message happens for all tests in a specific schema
Provide version info
utPLSQL v3.1.6.2735, Database version 18.5.0.0.0
port_string: x86_64/Linux 2.4.xx
Information about client software
To Reproduce
Steps to reproduce the behavior:
- Create betwnstr/test_betweenstr packages from demo project
- EXECUTE ut.run('SCHEMA.test_betwnstr');
- See error
Between string function
Returns substring from start position to end position [,003 sec] (FAILED - 1)
Returns substring when start position is zero [,002 sec] (FAILED - 2)
Returns string until end if end position is greater than string length [,002 sec] (FAILED - 3)
Returns null for null input string value [,002 sec] (FAILED - 4)
A demo of test raising runtime exception [,002 sec] (FAILED - 5)
A demo of failing test [,002 sec] (FAILED - 6)
Demo of a disabled test [0 sec] (DISABLED)
Failures:
- normal_case
Call params for test are not valid: package does not exist or is invalid: SCHEMA.TEST_BETWNSTR
- zero_start_position
Call params for test are not valid: package does not exist or is invalid: SCHEMA.TEST_BETWNSTR
- big_end_position
Call params for test are not valid: package does not exist or is invalid: SCHEMA.TEST_BETWNSTR
- null_string
Call params for test are not valid: package does not exist or is invalid: SCHEMA.TEST_BETWNSTR
- bad_params
Call params for test are not valid: package does not exist or is invalid: SCHEMA.TEST_BETWNSTR
- bad_test
Call params for test are not valid: package does not exist or is invalid: SCHEMA.TEST_BETWNSTR
Finished in ,014138 seconds
7 tests, 0 failed, 6 errored, 1 disabled, 0 warning(s)
Expected behavior
Should be successfully run as in another schema in the same database.
Example code
betwnstr/test_betweenstr packages from demo project
Additional context
Maybe this is grant / object related (eg. duplicate system views in the schema or similar) Activitylwasylow commented on Mar 29, 2019 Hi @tkleiber
Who is the owner of the tests packages and who is executing the tests ?
Does the schema executing tests have execute on the tests packages ? tkleiber commented on Mar 29, 2019 The owner is executing the tests, therefore I don't understand why this error occurs. jgebal commented on Mar 29, 2019 Is the failure message containing exactly:
SCHEMA.TEST_BETWNSTR or did you modify it? tkleiber commented on Mar 29, 2019 Have renamed only the schema to hide company informations. jgebal commented on Mar 29, 2019 You mentioned duplicate system views in schema. Is this something that you have?
utPLSQL is based on access to some system views so if you have duplicated system views in SCHEMA that could be the problem.
Another possibility is that there are some changes in 18.5 to how dbms_sql / dynamic sql works.
Can you reproduce the same problem in any schema or is it only this one schema that is causing issues? tkleiber commented on Mar 30, 2019 System views was only an idea, but I could not found any dba-, user- or all-views in the meantime. As already mentioned in another schema all runs fine.
Should I run them same selects and debug statement as in the last issue? jgebal commented on Mar 30, 2019 That would be helpful.
I will not be able to work on urPLSQL within next two weeks however. tkleiber commented on Apr 1, 2019 jgebal commented on Apr 18, 2019 Hi @tkleiber
Is this still an issue for you?
Unfortunately I can't reproduce this issue on the DB versions I have at hand.
I'll add some extra debug info into 3.1.7-develop to help investigate the problem.
Two questions:
- is this an issue related to 3.1.6 - do you have same issue with older versions of utPLSQL?
- is this an issue related to DB version - do you see same issue on older versions of DB?
If you can help us narrow-down the problem - that will help a lot. jgebal commented on Apr 18, 2019 Also, is the package TEST_BETWNSTR actually valid?
The reason to get this exception is when:
- package is not visible to user
- package is not valid
So there are only three possibilities:
- test package is not visible to user
- test package is not in valid state (spec)
- we have an issue inside utPLSQL with package state validation.
tkleiber commented on Apr 23, 2019
is this an issue related to 3.1.6 - do you have same issue with older versions of utPLSQL?
I have seen this before on 3.1.3, so therefore I have updated to 3.1.6 before I opened this issue to create it for the actual version.
is this an issue related to DB version - do you see same issue on older versions of DB?
This issue is not reproducable on 11.2.0.4 EE, we are on the way to migrate to 18.5.0.0 EE and running successfully the utPLSQL tests is the first step to verify this migration.
test package is not visible to user
The user ownes the package and so it is visible.
test package is not in valid state (spec)
Test package and body TEST_BETWNSTR and the function BETWNSTR are valid and owned by the calling user.
we have an issue inside utPLSQL with package state validation.
Seems that this remains!?
As already mentioned: If I call the same test from another user, to which is granted execute grants to the owner package and function, all run as expected. jgebal commented on Apr 28, 2019 Since I cannot reproduce it on any of DB's we have:
-11g, 12.1, 12.2, 18, 19, can you please check which part of the validation fails for you?
This could indicate an Oracle DB issue - maybe a bug in 18.5 version you have installed:
declare
function is_object_visible(a_object_name varchar2) return boolean is
l_invalid_object_name exception;
pragma exception_init(l_invalid_object_name,-44002);
begin
return dbms_assert.sql_object_name(a_object_name) is not null;
exception
when l_invalid_object_name then
return false;
end;
function get_dba_view(a_dba_view_name varchar2) return varchar2 is
l_result varchar2(128) := lower(a_dba_view_name);
begin
if not is_object_visible(a_dba_view_name) then
l_result := replace(l_result,'dba_','all_');
end if;
return l_result;
end;
function get_objects_view_name return varchar2 is
begin
return get_dba_view('dba_objects');
end;
function form_name(a_owner_name varchar2, a_object varchar2, a_subprogram varchar2 default null) return varchar2 is
l_name varchar2(200);
begin
l_name := trim(a_object);
if trim(a_owner_name) is not null then
l_name := trim(a_owner_name) || '.' || l_name;
end if;
if trim(a_subprogram) is not null then
l_name := l_name || '.' || trim(a_subprogram);
end if;
return l_name;
end form_name;
procedure do_resolve(a_fully_qualified_name in varchar2,a_context in integer,a_owner out nocopy varchar2, a_object out nocopy varchar2,
a_procedure_name out nocopy varchar2) is
l_dblink varchar2(200);
l_part1_type number;
l_object_number number;
begin
dbms_utility.name_resolve(name => a_fully_qualified_name
,context => a_context
,schema => a_owner
,part1 => a_object
,part2 => a_procedure_name
,dblink => l_dblink
,part1_type => l_part1_type
,object_number => l_object_number);
end;
procedure do_resolve(a_owner in out nocopy varchar2, a_object in out nocopy varchar2, a_procedure_name in out nocopy varchar2) is
l_name varchar2(200);
l_context integer := 1; --plsql
begin
l_name := form_name(a_owner, a_object, a_procedure_name);
do_resolve(l_name,l_context,a_owner,a_object, a_procedure_name);
end do_resolve;
function package_valid(a_owner_name varchar2, a_package_name in varchar2) return boolean as
l_cnt number;
l_schema varchar2(200);
l_package_name varchar2(200);
l_procedure_name varchar2(200);
l_view_name varchar2(200) := get_objects_view_name;
begin
l_schema := a_owner_name;
l_package_name := a_package_name;
do_resolve(l_schema, l_package_name, l_procedure_name);
execute immediate q'[select count(decode(status, 'VALID', 1, null)) / count(*)
from ]'||l_view_name||q'[
where owner = :l_schema
and object_name = :l_package_name
and object_type in ('PACKAGE')]'
into l_cnt using l_schema, l_package_name;
-- expect both package and body to be valid
return l_cnt = 1;
exception
when others then
dbms_output.put_line(dbms_utility.format_error_stack()||dbms_utility.format_error_backtrace());
return false;
end;
begin
if package_valid('SCHEMA','TEST_BETWNSTR') then
dbms_output.put_line('PACAKGE VALID');
else
dbms_output.put_line('!!!pacakge not vaild');
end if;
end;
/If you manage to find which part of validation is failing, we can re-visit it and adjust.
There seems to be a bit too much going on for pre-test-run validation anyways. tkleiber commented on Apr 29, 2019 Here is the output of this code:
ORA-04047: object specified is incompatible with the flag specified
ORA-06512: at "SYS.DBMS_UTILITY", line 156
ORA-06512: at line 46
ORA-06512: at line 61
ORA-06512: at "SYS.DBMS_UTILITY", line 156
ORA-06512: at line 46
ORA-06512: at line 61
ORA-06512: at line 75
!!!pacakge not vaild lwasylow commented on Apr 29, 2019 Can you add some dbms output so we can see variables values ? Replace a do_resolve with something like these
procedure do_resolve(a_owner in out nocopy varchar2, a_object in out nocopy varchar2, a_procedure_name in out nocopy varchar2) is
l_name varchar2(200);
l_context integer := 1; --plsql
begin
l_name := form_name(a_owner, a_object, a_procedure_name);
dbms_output.put_line('Full name: '||l_name);
dbms_output.put_line('a_owner name: '||a_owner);
dbms_output.put_line('a_object name: '||a_object);
dbms_output.put_line('a_procedure_name: '||a_procedure_name);
do_resolve(l_name,l_context,a_owner,a_object, a_procedure_name);
end do_resolve;
tkleiber commented on Apr 29, 2019 The problem can be stripped down to:
DECLARE
a_fully_qualified_name VARCHAR2(32767) := 'SCHEMA.TEST_BETWNSTR';
-- a_fully_qualified_name VARCHAR2(32767) := 'SYS.DBMS_UTILITY';
a_context INTEGER := 1;
a_owner VARCHAR2(32767);
a_object VARCHAR2(32767);
a_procedure_name VARCHAR2(32767);
l_dblink varchar2(200);
l_part1_type number;
l_object_number number;
BEGIN
dbms_utility.name_resolve(name => a_fully_qualified_name, context => a_context, schema => a_owner, part1 => a_object, part2 => a_procedure_name, dblink => l_dblink, part1_type => l_part1_type, object_number => l_object_number);
END;
/I will try to open a SR at Oracle tomorrow. Reacted by Lukasz Wasylow jgebal commented on Apr 29, 2019 We will change our code not to rely on this feature. We cpuld probably get away with using dbms_assert jgebal commented on Apr 30, 2019 @tkleiber - do you happen to have any object that is named the same as schema name in your schema?
If so - this is the reason for the problem.
For example:
create or replace package schema.schema is
procedure nothing_meaningful;
end;
/ tkleiber commented on Apr 30, 2019 Yes - there was a table with same name as the schema.
Now the tests work fine!
Is this a known Oracle bug? jgebal commented on Apr 30, 2019 PhilippSalvisberg commented on Apr 30, 2019 added a commit that references this issue on Jun 15, 2019This issue will close once commit 85942e9 is merged into the 'develop' branch.85942e9 added a commit that references this issue on Jun 18, 2019This issue will close once commit 1a5c525 is merged into the 'develop' branch.1a5c525
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|