Developer SQL 3 EA1: Unit Test

Similar Questions

• Unit testing: why white spaces are added to the PL/SQL lines on each edition?

  Dear team of SQL Developer,

  Are you aware of this very annoying problem of the unit test is running: a space is added to each line of PL/SQL code with each unit test that is run?

  The length of each line of code continues to grow with each race...

  I wonder why is it and you have an existing reference to bug for this... Please let me know...

  Thank you

  Val

  Thank you, Gary!

  The bug was just connected:

  BUG 20061594 - UNIT TESTS: the UNWANTED SPACE CHARACTERS ADDED to THE SQL CODE

  I've updated the SR that white spaces are added after each change, and that it can be easily mistaken for each run (we open the editor for see/check, or simply to do an update before a new race), but the bug has already been created with a description of the problem of evil:

  "...

  Description of the problem

  ===================

  Spaces are added after each line of SQL in the Unit Test after each race. »

  Sorry about that... I hope that the bug will be updated with correct description before you guys accept it as a bug:

  "...

  Description of the problem

  ===================

  Spaces are added after each line of SQL in the Unit Test after each change. »

  Thanks again,

  Val

• PL/SQL, used in application of the APEX of unit tests

  question by my client:

  I develop an Oracle Application Express application and work on unit tests for stored procedures in PL/SQL and the packages that are stored in the underlying database and used by the application of the APEX. These unit tests must run in the context of SQL Developer Unit Test.
  The problem is that the PL/SQL code stored in the database using functions such as NV('APPLICATION_ITEM') to access items in the application of the apex. They do return all values when I try to execute the PL/SQL within the unit test framework, that is to say in the backend. While it is good that the NV is not error, NULL haven't really work well in my scenario either (for example when the result of this function is inserted into a column NOT NULL in a table). I can think of a few workarounds, such as the creation of my own function NV within the schema to test return values desirable, but nothing seems a really satisfactory solution. I wonder if there is no recommendation to Oracle for this scenario - how can I run code that uses the APEX via backend-specific features. I found nothing in the documentation of the APEX for this but I would like to know if there is a recommendation how to better deal with this case.
  
  I use SQL Developer version 4.0.0.13.80

  Hello

  Indeed, you must set your PL/SQL function calls. This would be the cleanest solution.

  There is an alternative. Please see the following article on the creation of an APEX in PL/SQL session: Martin Giffy D'Souza on Oracle APEX: how to create a Session of the APEX in PL/SQL

  This approach allows to set the values of APEX application item before you run your unit tests. I don't know if it's possible in SQL Developer Unit Test, but it might get you further down the road.

  Good luck

  Nick

• SQL Developer 3.0 EA 1 Advanced support for the type of data in the unit tests

  Hello
  
  According to SQL Developer 3.0 EA 1 New Feature List (http://www.oracle.com/technetwork/developer-tools/sql-developer/rel3-featurelist-ea1-166831.html#ut)
  the EA 1 version 3.0 supported advanced data types in the unit tests. This means support the ANYDATA and RECORD types? I installed version 3.0 of EA 1 to CentOS linux, but it seems that those advanced types are not supported yet. When I try to add a unit test for a function that returns the record type, I get quick error: "the return of PL/SQL RECORD type is not supported. Cannot test (function_name) because 1 arguments have not supported for types". Also if I try to unit test procedure which parameter is of type ANYDATA, I get quick error: "the type UNDEFINED P_DATA argument is not supported. Cannot test (procedure_name) because 1 arguments have not supported for types". Are those advanced data types supported in SQL Developer 3.0 FINAL version?
  
  Thank you
  Miikka L
  
  Edited by: user12844253 the 27.10.2010 16:31

  Hi Mikka,

  Only simple PL/SQL records are currently supported i.e. those containing no optional or repeating components and where all components are themselves supported. This restriction is in place, due to the fact that we are using JDBC as a parameter mechanism which does not directly support the passage the PL/SQL record type.

  ANYTYPE and ANYDATA are currently not supported because they have a dynamic value type and must be set programmatically. In the future, it would be possible to support these via the dynamic value and and validation features.

  This will remain for the final version.

  Kind regards
  Richard

• sql question 4.1.1.19.59 of unit test developer

  Hello

  4.1.1.19 version build HAND - 19.59 I had a problem to run the unit tests with exception as expected result. No matter if I say "ANY" or specify an error number. All the tests fail. Must be a bug.

  

  Kind regards.

  SQL Developer restarting solves the problem.

• Unit test in sql developer 4.1 fails but passes in 4.0

  I can't tell if it's a question of Java or Sql * developer issue.

  SQL * Developer Version: 64-bit 4.1.0.17.29

  Versions of Java: Tried jdk 8: 1.8.0_5, 1.8.0_20 and 1.8.0_31 - all 64 bits

  That is the message in the response of unit test:

  CPS_TOOLS.PREP_FOR_DELIMITED_FIELD failed: Missing defines
  oracle.jdbc.driver.Accessor.isNull(Accessor.java:744)
  oracle.jdbc.driver.CharCommonAccessor.getString(CharCommonAccessor.java:350)
  oracle.jdbc.driver.OracleCallableStatement.getString(OracleCallableStatement.java:661)
  oracle.jdbc.driver.OracleCallableStatementWrapper.getString(OracleCallableStatementWrapper.java:860)
  oracle.jdbc.proxy.oracle$1dbtools$1raptor$1proxy$1driver$1oracle$1RaptorProxyOJDBCStatement$2oracle$1jdbc$1internal$1OracleCallableStatement$$$Proxy.getString(Unknown Source)
  oracle.dbtools.raptor.datatypes.strategies.callablestatement.CallableBindingVARCHAR.customOutputByPosition(CallableBindingVARCHAR.java:51)
  oracle.dbtools.raptor.datatypes.strategies.callablestatement.CallableBindingDatumAtName.customOutput(CallableBindingDatumAtName.java:123)
  oracle.dbtools.raptor.datatypes.impl.CallableBindingImpl.getOutput(CallableBindingImpl.java:74)
  oracle.dbtools.unit_test.testObjects.UtTestImplArgs.getOutput(UtTestImplArgs.java:320)
  oracle.dbtools.unit_test.runner.Runner.executeRunn ...
  
  
  

  Now, the same unit test works with the following text:

  SQL * Developer Version: 64-bit 4.0.2.15

  The Versions of Java: 64 bit jdk 7 - 1.7.0_55

  I tried to follow here debug information collection:

  http://www.thatjeffsmith.com/archive/2012/06/how-to-collect-Debug-Info-for-Oracle-SQL-Developer/

  However, there is no report in the command window after a ctrl-pause/break. At the same time, however, it is not like sql * developer hangs here.

  Thoughts?

  EA 4.1 includes a new feature to save all JDBC calls (view > Log, and then note the statements tab in the logs pane), so it could be the difference in the behavior of Test Unit between 4.0 and 4.1.

  You use the JDBC default 12.1 driver, or you have overridden by specifying a particular Oracle client?  In other words, in

  Tools > Preferences > Database > advanced > use Oracle client > configure...

  
  

  I read that somewhere there may be problems when you use the clients pre - 12 c with earlier versions of JDBC. driver

• Is there a real BENEFIT in SQL * Developer Automated Unit Testing?

  I'm trying to understand the unit test in SQL * Developer. Asked me to evaluate it as a method of test automation on an integration solution that we develop.

  (1) my 'A' schema has this table:

  SQL > DESC EMP

  Name                                      Null?    Type

  ----------------------------------------- -------- --------------------

  EMPID NOT NULL NUMBER

  EMPNAME VARCHAR2 (30)

  SALARY NUMBER (7.2)

  COMM_PCT NUMBER (2.2)

  Table (2). has these values:

  SQL > SELECT * from emps;

  EMPID EMPNAME SALARY COMM_PCT

  ---------- ---------- ---------- ----------

  1 ROHAN 10000.05

  2 JOHN 20000

  3 PETER.06

  4 SMITH

  (3.) I create this procedure in drive A:

  create or replace

  PROCEDURE award_bonus (NUMBER, sales_amt NUMBER p_empid)

  AS

  REAL Commission;

  comm_missing EXCEPTION;

  BEGIN

  SELECT comm_pct IN the commission OF EMP

  WHERE empid = p_empid;

  IF the commission IS NULL THEN

  RAISE comm_missing;

  ON THE OTHER

  PGE UPDATED

  SET salary = salary + sales_amt * commission

  WHERE empid = p_empid;

  END IF;

  END award_bonus;

  (4) now, I want to create a unit test in SQL Developer to test this procedure.

  (5) I created a user "unit_test_repos" according to the instructions in the tutorial.

  (6) ' SELECT OPERATION': I specifies the procedure of award_bonus.

  (7) ' SPECIFY the name of test': give a name and select "create with a single model.

  (8.) 'SPECIFY the STARTUP': Add a ' copy Table or the line "the startup process.

  -I give "EMP" as the source table.

  -And then I get this for the 'generated query.

  SELECT ROWID AS SRC$ ROWID, s.* FROM EMP s

  -Target table has "TMP$ AWARD_BONUS.

  (Q1) WHAT IS THE PURPOSE OF CREATING ANOTHER TABLE?

  (Q2) WHEN THE TEST IS DONE, ARE ROWS OF PGE copied into this table?

  (Q3) Why is this? Why can't the test simply read 'EMP '?

  (9) "PARAMETERS SPECIFY": I give "Input".

  -1 for P_EMPID

  -10000 for SALES_AMT

  -In "Expected result", I say "success."

  (Q4) So I should know in my mind the results of the proc, foregoing given entries?

  (10) ' SPECIFY VALIDATION': I add validation "poll rows of queries.

  -I paste the following query: SELECT count (*) FROM EMP WHERE empid = 1 AND salary = 10500

  -that is, I know that for an amount of 10000 sales, employee 1 will get a Commission of 10000*.05 = 500. For example, 10000 (its sal) + 500 = 10500.

  (Q5) The thought that the above is correct?

  (11) "TEARDOOWN SPECIFY": give nothing.

  (12) my unit test is created.

  (13.) I run now by clicking on the button of the beetle, to the left of the green arrow. Unit test is run.

  (14) now in my table a.emps, 1 salary has increased to 10 500, and the diag test case, I get the "execution results: SUCCEED.

  (15) now, I run the unit test again.

  (16.) salary 'EMP' table emp 1 is passed to 11000 (which is correct) and the so-called execution results "SUCCESS".

  (Q6)  My question is: the query I gave for validation, SELECT count (*) FROM EMP WHERE empid = 1 AND = 10500 salary, now gives 0. so, this means that no row is returned for this condition and so the test must FAIL. But how is SQL * Developer said that the test was SUCCESSFUL. How does this system of validation?

  (17.) I went through the tutorial, but I do not understand these concepts >

  (Q7) What is the purpose of disassembly? I undersand the option 'drop table' "disassembly", where you drop the temporary table, but I do not understand the others, 'Table or line restore' and 'code pl/sql user '?

  (Q8) WHAT IS the advantage of making the test like this? Can I use an Excel spreadsheet and make dozens of unit tests faster than this method?  It is easy to understand too. This method is complicated.

  Your answers and your advice would be greatly appreciated.

  The temporary table to hold the original values for EMP. After the test runs, you must configure the disassembly to reset the return values of the temporary for the next time table that the test works again, he has values of expected start.

• SQL Developer 3.0 EA1 creates account names case senstive

  Hello
  
  When you create a new account with SQL Developer 3.0 EA1, the username is enclosed in quotes. This creates an account name of case-sensitive which creates problems when you try to sign. Historically, the account names have been converted to uppercase internally and during the logon sequence this is expected behavior. Not sure why SQL Developer 3.0 EA1 team has chosen to start encapsulating user names when creating quotes?
  
  Example of a create user statement of 2.0
  
  -SQL USER
  Why_this_old_way CREATE USER IDENTIFIED BY scott;
  
  -ROLES
  GRANT "RESOURCE" FOR why_this_old_way;
  GRANT "CONNECT" to why_this_old_way.
  
  Example of a create user statement of 3.0 EA1.
  
  -SQL USER
  CREATE USER 'why_this_new_way' IDENTIFIED BY scott;
  
  -ROLES
  GRANT the "RESOURCE" to "why_this_new_way";
  GRANT 'CONNECT' to 'why_this_new_way ';
  
  Having the names of case-sensitive objects significantly increases the complexity unnecessarily, please do not implement this approach.
  
  Scott K.

  There was a change made to address another issue that caused this problem. I supported this behavior will return following EA (when it exists) or the Production version.

  Syme

• Unit test SQL dev 4.1.3.20 missing permissions - but that

  I asked my dba for necessary roles and permissions to perform unit tests,

  Roles and permissions for these are - according to the documentation:

  CREATE THE UT_REPO_USER ROLE.

  GRANT SELECT ON DBA_TAB_PRIVS TO UT_REPO_USER;

  GRANT EXECUTE ON DBMS_LOCK TO UT_REPO_USER;

  CREATE THE UT_REPO_ADMINISTRATOR ROLE.

  GRANT UT_REPO_USER TO UT_REPO_ADMINISTRATOR;

  I checked that these roles and permissions actually exists

  In addition to that my users have these permissions (among many others)

  GRANT TO PASSWORD RESOURCE;

  GRANT CONNECT TO PASSWORD.

  GRANT CREATE VIEW TO PASSWORD.

  SELECT GRANT WE DBA_ROLES TO MY_USER;

  GRANT SELECT ON DBA_ROLE_PRIVS TO MY_USER;

  GRANT UT_REPO_ADMINISTRATOR TO PASSWORD.

  When I try to create a repository I get this message

  

  What Miss me?

  regards Karsten

  Discovered what was missing:

  ADMINISTRATOR should grant permissions directly to the user to unit test.

  Unit test does not accept the permissions granted to the public or by a role.

  I think it is a bug and I mention as such

  regards Karsten

• Unit test: disassembly of the table or restore the line failed: ORA-06502: PL/SQL: digital error or value: string buffer too small ORA-06512: at line 22

  Is any idea available in the process of disassembly of the table or restore the line to line 22?

  I see a bunch of discussions on the subject, but no clear solution/answer...

  What could be the causes of this error?

  I had two process of disassembly on the level now, and one of them had failed with this error. Displacement of the failure of the process of disassembly compared to the level of the suite for the level of performance of test unit solved the error for a while, but after some more dragging the process of disassembly of the table (with about 500 cases) is permanent.

  Please advise...

  Thank you

  Val

  Well, had to create a bug officially... I hope this helps...

  Bug 19696042 : UNIT TEST: disassembly of THE TABLE or LINE RESTORE failed: ORA-06502: STRING BUFFER TOO SMA

  Thank you

  Val

• Automation of unit tests for the development of the ATG

  Hello
  I'm trying to set up unit tests automated to ATG. Is there anyone who has had success with this? I searched the whole forum and there is no indication in this sense. Is there anyone doing TDD for ATG?
  
  I've tried the ATG dust, but it is not useful and has many gaps. Anyone succeeded with other frameworks such as Mockito, needle, EasyMock etc. ? Any help is appreciated.
  
  It will be interesting to know what the ATG developers use for unit tests.
  
  Thank you.

  You can try Mockito.

  Setup
  1 initialize the component to be tested (Formhandler/repository/droplet etc.) and possible data (form entries etc.).
  2 mock, the calls of the method required when using method in mockito.

  Test
  1. write all possible test methods.
  2 when use, check the methods in Mockito for testing your methods.
  3. you can also use assertions to test the results (Ex: form errors)

• 2.1.0.62: problem with Package.Functions and Unit Tests

  I like the new Sqldeveloper - I startet try Unit Tests as described here: link: [http://www.oracle.com/technology/obe/11gr2_db_prod/appdev/sqldev/sqldev_unit_test/sqldev_unit_test.htm#t4]
  
  He has worked with a test procedure. Now I'm testing my package functions, but all I get is the following:
  
  ---------
  Die Prozedur ausgeführt wurde following.
  
  Ausfuhrungsaufruf
  BEGIN
  : 1: = "PKG_MYPACK". "CREATEFUNCTION"(IN_PROGRAMMEID = >: 2,) "
  IN_AMOUNT = >: 3,.
  (IN_SWS = >: 4);
  END;
  
  Bind-variables verwendet
  1 WHOLE (NULL)
  INTEGER 2 IN 1
  INTEGER FROM 3 TO 10
  INTEGER 4 TO 11
  
  Ausfuhrungsergebnisse
  ERROR
  Ungultige conversion angefordert
  oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:70)
  oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:110)
  oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:171)
  oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:227)
  oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:439)
  oracle.jdbc.driver.OraclePreparedStatement.setObjectCritical(OraclePreparedStatement.java:7723)
  oracle.jdbc.driver.OraclePreparedStatement.setObjectInternal(OraclePreparedStatement.java:7496)
  oracle.jdbc.driver.OraclePreparedStatement.setObjectInternal(OraclePreparedStatement.java:7978)
  oracle.jdbc.driver.OracleCallableStatement.setObject(OracleCallableStatement.java:4063)
  oracle.jdbc.driver.OraclePreparedStatementWrapper.setObject(OraclePreparedStatementWrapper.java:221)
  oracle.dbtools.raptor.datatypes.strategies.callablestatement.CallableBindingDatum.customBindIN(CallableBindingDatum.java:135)
  Oracle. ...
  ------
  
  What can I do?

  Created
  Bug 8976245 - EA1: UNIT_TEST: CONVERSION not VALID ERROR with the HELP of the INTEGER PARAMETER
  and asked the answering machine of bug to keep you informed about the situation here in the forum.

  Bad news, it is that any INTEGER type parameter for which you specify a non-null value will fail.

  Possibly useful new, is that if you create a "clone" of you the function using NUMBER as the data type, you can continue to experiment how unit tests can be useful for you.

  Answer no sorry moment. :(

  Brian
  SQL development team

• Unit test: calculation of the length of the different columns in recordsets provided and received led to false a test failure

  Dear team of SQL Developer,

  It seems that the calculation of the length of the column in the expected and received recordsets behaves differently in some cases (when stored proc variables are used in the generation of the REF CURSOR, despite the explicit definition of the type of record): the length of the header and the length of the value in the set of records received are truncated to arbitrary length based on the returned value which leads to a false failure of a unit test. I.e. registries are the same in both sets of records, but the test run fails to the comparison of the recordsets because of different length. Please see the screenshot below:

  

  Here's the test case if you need to reproduce the problem/bug in your environment:

  1. use the default schema of HR of the Oracle examples package that comes with an 11 g database.

  2. change the HR. Table EMPLOYEES with the addition of a new column VARCHAR2 (4000) LONG_LAST_NAME:

  ALTER TABLE HR. EMPLOYEES

  ADD (LONG_LAST_NAME VARCHAR2 (4000));

  Update hr.employees set long_last_name = last_name;

  commit;

  3. create a PKG_TEST2 package with the source code below in the HR schema:

  ----------------------------------------------------------------------------------------------------------------------

  create or replace PACKAGE PKG_TEST2 AS

  TYPE EmployeeInfoRec IS RECORD

  (

  long_last_name employees.long_last_name%TYPE,

  first name employees.first_name%TYPE,

  E-mail employees.email%TYPE

  );

  TYPE EmployeeInfoRecCur IS REF CURSOR RETURN EmployeeInfoRec;

  FUNCTION getEmployeeInfo (p_Emp_Id employees.employee_id%TYPE)

  RETURN EmployeeInfoRecCur;

  END PKG_TEST2;

  ----------------------------------------------------------------------------------------------------------------------

  CREATE OR REPLACE PACKAGE BODY PKG_TEST2 AS

  FUNCTION getEmployeeInfo (p_Emp_Id employees.employee_id%TYPE)

  RETURN EmployeeInfoRecCur AS

  v_EmployeeInfoRecCur EmployeeInfoRecCur;

  v_LongLastName varchar2 (4000);

  BEGIN

  Select long_last_name from v_LongLastName

  employees

  where employee_id = p_Emp_Id;

  --

  OPEN FOR V_EmployeeInfoRecCur

  V_LongLastName SELECT long_last_name,

  first name,

  E-mail

  This_is_very_long_table_alias employees

  WHERE employee_id = p_Emp_Id

  order by 1 CSA;

  --

  RETURN v_EmployeeInfoRecCur;

  EXCEPTION

  WHILE OTHERS THEN

  LIFT;

  END getEmployeeInfo;

  END PKG_TEST2;

  
  

  ----------------------------------------------------------------------------------------------------------------------

  4. create a unit test for the PKG_TEST2.getEmployeeInfo stored procedure: (click the command create Test, select the stored procedure, click Ok for the pop-up message, click Next, click Finish).

  5. update the default value of dynamic query of value with the one below and save/post changes.

  Select the cursor)

  SELECT long_last_name,

  first name,

  E-mail

  Employees

  WHERE employee_id = idqry.employee_id

  order of the 1 CAD

  ) RETURNS $,.

  idqry.employee_id as P_EMP_ID

  from (select employee_id

  employees

  where rownum < = 5) idqry

  6. run the unit test newly created in the debug mode to display the shot.

  Thus, the record type 'EmployeeInfoRec' in the package clearly defines the LONG_LAST_NAME as VARCHAR2 (4000) through reference for the data type of column in the referenced table.

  But for some reason, the SQL Developer does not calculate correctly its length in the recordset "Receipts" If a variable is used (could be one as variable simple varchar2 in this reproducible test or complex variable of type of the object).

  Any ideas on that? Looks like another bug...

  Thank you

  Val

  The bug has been reproduced by the SRB and documented within the system of Support of Oracle SQL Developer team to pick it up:

  Bug 19943948 - TEST UNIT RETURNS EXPECTED ERROR: [LONG_LAST_NAME

  Hope the bug name can later be changed to something more descriptive, but it is not really... my only concern is the speed at which the known bugs would be fixed...

  Thank you

  Val

• Problem with Unit Test

  What I am doing wrong?

  I created a small example of how to test the functionality of substitution of variables within the unit test framework.

  Documentation: SQL Developer: unit tests

  create or replace procedure SimpleTestProcedure (param1 in varchar2) as

  Start

  null;

  end SimpleTestProcedure;

  /

  Test configuration with the following configuration:

  Input value: Test

  Process: Boolean function

  declare

  Param varchar2 (4 char);

  Start

  param: =: param1;

  If "{param1}"! = param then

  Returns false;

  end if;

  end;

  

  Is found in the following message is displayed after the test run:

  

  I use SQL Developer Version 4.0.3.16.

  Any help would be appreciated!

  Kind regards.
  

  Hi Flofe,

  It looks like the Boolean function as a validation of process takes no parameters that a function pl/sql 'generic' put... it's probably called "function" only because it returns a value, as does any function. But you can use substitutions of setting the parameters for the stored procedure that you are testing, which you are already doing.

  So, try to change your code to:

  declare

  Param varchar2 (8);

  Start

  param: = "{param1}";

  If "{param1}"! = param then

  Returns false;

  on the other

  Returns true;

  end if;

  end;

  And it should work for try you the little test...

  I hope this helps...

  Val

• Unit test: behavior another header in recordsets provided and received led to false a test failure

  Dear team of SQL Developer,

  It seems that the headers in the expected and received Recordset behaves differently: the headers of expression in the expected Recordset are truncated to 30 characters and the same expression in the set of records received headers are not truncated, which leads to a false failure of a unit test. That is that the records are the same in both sets of records, but the test run fails to comparison of sets of records due to the different headings. Please see the screenshot below:

  

  Here's the test case if you need to reproduce the problem/bug in your environment:

  1. use the default schema of HR of the Oracle examples package that comes with an 11 g database.

  2 create a PKG_TEST package with the source code below in the HR schema:

  ----------------------------------------------------------------------------------------------------------------------

  create or replace PACKAGE PKG_TEST AS

  TYPE EmployeeInfoRec IS RECORD

  (

  employees.last_name%type last_name,

  first name employees.first_name%TYPE,

  E-mail employees.email%TYPE

  );

  TYPE EmployeeInfoRecCur IS REF CURSOR RETURN EmployeeInfoRec;

  FUNCTION upperCaseLastName (p_Last_Name employees.last_name%TYPE)

  RETURN varchar2;

  FUNCTION getEmployeeInfo (p_Emp_Id employees.employee_id%TYPE)

  RETURN EmployeeInfoRecCur;

  END PKG_TEST;

  ----------------------------------------------------------------------------------------------------------------------

  CREATE OR REPLACE PACKAGE BODY PKG_TEST AS

  FUNCTION upperCaseLastName (p_Last_Name employees.last_name%TYPE)

  RETURN varchar2 AS

  BEGIN

  RETURN upper (p_Last_Name);

  END upperCaseLastName;

  FUNCTION getEmployeeInfo (p_Emp_Id employees.employee_id%TYPE)

  RETURN EmployeeInfoRecCur AS

  v_EmployeeInfoRecCur EmployeeInfoRecCur;

  BEGIN

  OPEN FOR V_EmployeeInfoRecCur

  SELECT upperCaseLastName (last_name),

  first name,

  E-mail

  This_is_very_long_table_alias employees

  WHERE employee_id = p_Emp_Id

  order by 1 CSA;

  --

  RETURN v_EmployeeInfoRecCur;

  EXCEPTION

  WHILE OTHERS THEN

  LIFT;

  END getEmployeeInfo;

  END PKG_TEST;

  ----------------------------------------------------------------------------------------------------------------------

  3. create a unit test for the PKG_TEST.getEmployeeInfo stored procedure: (click the command create test, select the stored procedure, click Ok for the pop-up message, click Finish).

  4. update the default value with the following dynamic query and save the changes.

  Select the cursor)

  SELECT pkg_test.upperCaseLastName (last_name),

  first name,

  E-mail

  This_is_very_long_table_alias employees

  WHERE employee_id = idqry.employee_id

  order of the 1 CAD

  ) RETURNS $,.

  idqry.employee_id as P_EMP_ID

  from (select employee_id

  employees

  where rownum < = 5) idqry

  5. run the unit test newly created in the debug mode to display the shot.

  The work around is to use an alias for the expression of long short, but our code is in Production, and we do not a new version whenever soon to add aliases... but we plan to use SQL Developer to automate our unit of PL/SQL code, tests once we clearly have some of the problems with the tool, we know...

  Please advise...

  Thank you

  Val

  Of course, Jeff... CS it logged as a bug... could be changed to apply for development later, I guess...

  BUG 19826375 - header BEHAVIOR IN the GAMES of RECORDS EXPECTED/RECEIVED LED to the ERROR

  Thank you

  Val