Pervasive
Sign in | Join | Help
in

I can't believe what I am seeing - Stored Procedure issue

Last post 08-07-2008 11:11 AM by The Dread Pirate Roberts. 6 replies.
Page 1 of 1 (7 items)
Sort Posts: Previous Next
  • 06-12-2008 3:04 PM

    I can't believe what I am seeing - Stored Procedure issue

    Given the following stored procedure

     CREATE PROCEDURE Test1(out :Value integer, in :Input integer)

    AS

    BEGIN

     

    SET :Value = :Input;

     

    END

    The following code FAILS...

    DbConnection conn = PsqlFactory.Instance.CreateConnection();

    conn.ConnectionString = "xxx";

    DbCommand cmd = PsqlFactory.Instance.CreateCommand();

    cmd.CommandType = CommandType.StoredProcedure;

    cmd.CommandText = "Test1";

    PsqlParameter param = PsqlFactory.Instance.CreateParameter() as PsqlParameter;

    param.ParameterName = "Input";

    param.Direction = ParameterDirection.Input;

    param.PsqlDbType = PsqlDbType.Integer;

    param.Value = 1;

    cmd.Parameters.Add(param);

    param =
    PsqlFactory.Instance.CreateParameter() as PsqlParameter;

    param.ParameterName = "Value";

    param.Direction = ParameterDirection.Output;param.PsqlDbType = PsqlDbType.Integer;

    cmd.Parameters.Add(param);

    cmd.Connection = conn;

    conn.Open();

    try

    {

    cmd.ExecuteNonQuery();

    }

    finally

    {

    conn.Close();

    }

    Here is the error that's received...

    Pervasive.Data.SqlClient.Lna.LnaException: [LNA][Pervasive][ODBC Engine Interface]Parameter Input/Output type does not match stored procedure definition

    If the code switches the order of the parameters, or the proc switches them to match the code, it works fine.  What is the point of having named parameters in a stored procedure if you have to match the order.  This is a huge issue for me.  I should not have to write code such that my parameters follow the exact order as they are designated in the procedure.

    Please advise.

  • 06-12-2008 3:17 PM In reply to

    Re: I can't believe what I am seeing - Stored Procedure issue

    I've been a programmer for a long time now, and calls to functions have ALWAYS required that the parameters be in the correct order.  Even C++, which allows defaulting of parameters in code, still has to have all parameters in the "right" order for it to work correctly, unless the developer overloaded the function AND the data types are different. 

    You defined the stored procedure with two parameters in a specific order.  Therefore, it only follows that you need to specify the parameters in the same order.  The "name" provided in the procedure definition is what allows the SP to access those values, and it is not intended to provide dynamic binding of the variables to the parameters. 

    Bill Bach
    Goldstar Software Inc.
    www.goldstarsoftware.com
  • 06-12-2008 3:36 PM In reply to

    Re: I can't believe what I am seeing - Stored Procedure issue

    Sql Server does not work like this.  So far as I'm aware, neither do Oracle and MySql.  Calling a stored procedure is not the same thing as calling a function in compiled code.

     This is completely non-functional from a coding perspective, especially with metadata driven architectures.  I now have to ensure that the parameters in my metadata tables are entered and retrieved in the exact order they are defined in the stored procedure.  This adds a huge amount of overhead and brings in the potential for coding errors.

  • 06-18-2008 11:36 AM In reply to

    Re: I can't believe what I am seeing - Stored Procedure issue

    BtrieveBill:

    I've been a programmer for a long time now, and calls to functions have ALWAYS required that the parameters be in the correct order.  Even C++, which allows defaulting of parameters in code, still has to have all parameters in the "right" order for it to work correctly, unless the developer overloaded the function AND the data types are different.

     

    At the risk of going off-topic....dynamic languages, such as Python, do allow you to pass named parameters in any order, with some limitations.

  • 06-18-2008 11:42 AM In reply to

    Re: I can't believe what I am seeing - Stored Procedure issue

    It's not really off topic.  Sql Server, Oracle, and My Sql all allow named parameters in any order when calling a stored procedure.  Parameterized queries in code have to be in the correct order, but that's not what I'm dealing with here.

  • 08-07-2008 10:13 AM In reply to

    Re: I can't believe what I am seeing - Stored Procedure issue

    We are investigating this issue regarding parameters order in a stored procedure and will let you know what we find.

  • 08-07-2008 11:11 AM In reply to

    Re: I can't believe what I am seeing - Stored Procedure issue

    Thanks, I appreciate that.  It would be less of an issue of the PsqlCommandBuilder's DeriveParameters worked correctly.  It gets the name and order correct, but often, the data type and parameter direction are not correct.

Page 1 of 1 (7 items)
© 2008 Pervasive Software Inc. All Rights Reserved.