ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

SQL CALL a stored procedure with parameters

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • SQL CALL a stored procedure with parameters

    Hi folks,

    I had this topic in CLLE programming first but now it is all about SQL, so I continue here.

    While I am convinced the fix is gonna be beyond trivial, I'm still probably doing all the things wrong that you cannot even think of.

    Here's my StoredProcedure:
    create or replace procedure MYLIB.STOREDPRC1 (IN USER_ID char(10), IN DBLIB char(10))
    --Delete for a given user from table USERS
    language SQL modifies SQL data
    begin
    set schema DBLIB;
    delete from USERS
    where USER = USER_ID
    with NC
    ;
    end


    And here's my SQL call statement:

    call STOREDPRC1 ('PAUL', 'DATALIB')

    Note that MYLIB is in my library list, as is DATALIB, and the STOREDPROC1 only exists in MYLIB. Still I get:
    SQL: Error -206, State 42704
    Joblog: SQL0206 - USERS in YSYS type *FILE not found.

    Ok, so the second parm DBLIB is used to do the 'set schema' but then the 'delete from' does not use the schema but defaults to YSYS, a library that does not exist in my library list for the job and definitely does not contain the database.

    So, I try with this instead:
    call STOREDPRC1 ('PAUL', DATALIB)
    ...and I get:
    SQL: Error -206, State 42703
    Joblog: SQL0206 - Column or global variable DATALIB not found.

    As I already indicated, the fix is probably easy as pie but no matter how much time I throw at it, it won't work for me.

    Any tips on how to gt this thing on the road are very welcome indeed.
    I'd also be interested to hear if a StoredProcedure could be debugged, and if so: how.


    -----------------
    Happy coding!
    Paul
    Sweden


  • #2
    I think I had a similar topic a long time ago.
    Thanks to the DB monitoring I figured out, that the problem belongs to naming convention *SYS vs. *SQL.
    With one of them the SET SCHEMA has been ignored. I was not sure if this was a bug or a feature

    So I changed to (I guess) *SQL naming and it worked.

    But as mentioned, it was a log time ago and I am not sure if I remember all in details.

    If it is still not working you should try to start the DB monitoring and see what's going on in detail.

    Greetings from austria
    Andreas

    Comment


    • #3
      Thanks, good point.

      ...I tried your reasonable proposal, but did not get it to work within hours, dunno why, same error occurred.

      So, after more than two weeks (!) of struggle with this, I finally decided to abandon the idea of using StoredProcs altogether. I ended up putting my SQLs in an RPG /free program and got it to work within hours.

      The reason for pursuing StoredProcs in the first place was to have the flexibility to slightly adjust the SQLs without needing to deploy a new version of the RPG programs around them. I have used StoredProcs before, but never with parameters, which broke this project.

      Comment


      • #4
        The problem is the different use of SQL and System Naming conventions.
        First the differences:
        1. When using system naming conventions everything works as we expect on the IBM i, i.e. unqualified specified objects are searched in the current library list.
        2. When using SQL naming conventions, unqualified specified tables, views and indexes are searched within the Default/Current Schema. The current schema is set with the SET SCHEMA SQL command. If a current schema is not set the schema with the same name as the current user profile is used. SQL Routines (Stored Procedures, User Defined (Table) Functions) are searched in the SQL Path. The SQL Path can be set with the SET PATH SQL Statement. In the SQL path multiple schemas can be specified and even the special value *LIBL is allowed.
        When setting the current schema in an environment where System naming conventions are used, the library list is no longer searched.

        When creating a database object, the naming conventions of the job are used. In the Green Screen interfaces (STRSQL or RUNSQLSTM) the default naming is System Naming conventions. In all graphical user interfaces (ACS, RDi, Squirrel, DBBeaver ...) is SQL Naming the default. In ACS Run SQL Script the naming can be set in the connection (Edit --> JDBC Connections --> Select your Connection - Edit --> Format). If you are using ACS Schemas for creating your procedure the naming can be set over Edit --> Preferences.

        When Creating a SQL routine (stored procedure or a UDF or UDTF) with SQL Naming conventions, the current/default schema for all unqualified specified database objects is resolved at compile time, i.e. taken from the environment or explicitly specified in the SET OPTION statement.
        So trying to set the Current/Default schema in the function at runtime will not affect anything (at least not if the SQL Routine was created with SQL Naming Conventions), since the database objects are already qualified within the SQL Routine.
        If the SQL routine was generated with System Naming conventions, the unqualified specified database objects are not resolved at compile time, but resolved at runtime in the library list. But if you then execute a SET SCHEMA Statement at runtime only this library is searched for unqualified specified database objects, while the library list is no longer searched.



        Last edited by B.Hauser; July 16, 2022, 01:26 AM.

        Comment


        • #5
          Here are 2 Articles about the differences when using SQL and System Naming Convention

          Comment


          • #6
            Hi Birgitta,
            Thanks. I did find both last week after Andreas' tip on SQL naming, but none solved my problem.

            In spite of being anxious to learn, there's a time limit on time for most things. I think I spent more time on this than I should have, so I finally returned to RPG embedded SQL.

            Usually, I can crack a problem like this with a code example or two, but no suitable ones were found on the ol' interweb. Given that, I deducted that StoredProcs on IBMi was probably not as widely used as I assumed and hoped them to be. When I started on this, I liked the idea that you can have the SQL outside of the application for better flexibility.

            Notes:
            • I tried with and without qualified table names: no difference
            • The set schema did not fix the problem, the SQL still looked for the table in the wrong library
            • The library parameter was mixed up as a table column, whatever the sequence of the parameters I tried

            Happy coding!
            -----------------
            Paul
            Sweden

            Comment

            Working...
            X