Results 1 to 9 of 9
  1. #1
    Join Date
    Jul 2004
    Posts
    30

    Angry Unanswered: grrrrr another problem in the form

    I have a plenty number of forms, and I have a table contains customer's information. One of the usage of this table (called
    customers) is to give the customer the authentication to access these forms. In the first form, the user should enter his
    password. After a check process, if the user is authinticated, his id (which is a field called customer_id) should be sent
    to the next form. I could use a parameter list for this, but i'm using a parameter list for sending another variable to be used
    in another purpose. I thought of using a function to return the customer_id but I faced a big problem in defining a constant
    that should keep the value of 'customer_id'. As it's know the constant should be declared in the declaration section, so what
    is sent will be the constant and it'll not hold the right value. The function I'm talking about is like the following:


    FUNCTION GET
    (cust in varchar2(4),
    flag in varchar2(4))
    RETURN VARCHAR2
    vcust constant varchar2(4) := cust;
    IS
    BEGIN
    if flag = '0' then
    RETURN ('0');
    else
    RETURN(vcust);
    end if;

    END;

    END;


    I thought of other solution which is creating a package that contains a procedure 'take' to save the constant, and a function
    'get' to return the constant saved in the 'take' procedure. But I don't know how to get the value inside the procedure!
    I tried the following way:

    PACKAGE BODY pkg IS

    :GLOBAL.B VARCHAR2(4);

    PROCEDURE TAKE ( FLAG IN VARCHAR2)
    IS
    LMN CONSTANT VARCHAR2(4) := FLAG;
    BEGIN
    ....
    END;




    FUNCTION GET RETURN VARCHAR2
    IS
    BEGIN
    RETURN (TAKE.LMN);
    END;

    END;

    well, this package caused me alot of errors. Regardlessing the errors, I'm not sure of the way I called the constant variable.

    If anyone has an idea to solve my problem, PLEASE tell me.
    thanks.

  2. #2
    Join Date
    Jun 2003
    Location
    West Palm Beach, FL
    Posts
    2,713

    Cool

    You can create the package like this:
    Code:
    Create Or Replace Package Pkg Is
    Lmn Varchar2(4) := Null;
    Procedure Take ( Flag In Varchar2);
    Function Get Return Varchar2;
    End Pkg;
    /
    
    Create Or Replace Package Body Pkg Is
    Procedure Take ( Flag In Varchar2)
    Is
    Begin
      Lmn := Flag;
    End;
    Function Get Return Varchar2
    Is
    Begin
      Return Lmn;
    End;
    End Pkg;
    /
    The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb

  3. #3
    Join Date
    Jun 2004
    Location
    Liverpool, NY USA
    Posts
    2,509
    another way (in oracle forms) is to use a global. Simply issue the following command in the original form

    :global.customer_id = :my_customer.customer_id;

    The global will be available in any form that you call.
    Bill
    You do not need a parachute to skydive. You only need a parachute to skydive twice.

  4. #4
    Join Date
    Jul 2004
    Posts
    30

    Thumbs up

    THANK YOU guys ....ill try it out

  5. #5
    Join Date
    Jun 2003
    Location
    West Palm Beach, FL
    Posts
    2,713

    Cool

    I don't know forms, but a global variable is best way, follow beilstwh's instructions.
    The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb

  6. #6
    Join Date
    Jan 2004
    Location
    Croatia, Europe
    Posts
    4,094
    Provided Answers: 4
    Global variables are OK if handled carefully, but have great potential to cause frustrating problems (a global variable whose value is not erased when you don't need it any more is a nightmare ).
    My opinion is: few forms - use global variable and handle them with care. Many forms - use parameter list.

  7. #7
    Join Date
    Jun 2003
    Location
    West Palm Beach, FL
    Posts
    2,713

    Cool

    Quote Originally Posted by Littlefoot
    Global variables are OK if handled carefully, but have great potential to cause frustrating problems (a global variable whose value is not erased when you don't need it any more is a nightmare ).
    My opinion is: few forms - use global variable and handle them with care. Many forms - use parameter list.
    Well, that's the obligation of the programmer! Keep track of every aspect of the application.
    Bad programmers forget to initialize/erase/update their GLOBAL variables!
    Not a DB problem...
    The person who says it can't be done should not interrupt the person doing it. -- Chinese proverb

  8. #8
    Join Date
    Jan 2004
    Location
    Croatia, Europe
    Posts
    4,094
    Provided Answers: 4
    I have nothing to add to it, LKBrwn_DBA.
    Bad programmers, bad!

  9. #9
    Join Date
    Jul 2004
    Posts
    30
    Thankx it worked

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •