Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

SQL and ILE

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

  • SQL and ILE

    Try encapsulating all the IO for a given file in sub procedures in a single service program. Use externally described multiple occurance data structures and use the FOR n ROWS clause in the FETCH statement to load the data structure. Pass back an EOF indicator as well. Create other procedures to prepare, declare, open and close the cursor as needed. Sounds like fun!

  • #2
    SQL and ILE

    It's going to be a lot of work, but that does sound like the best way to go.

    Comment


    • #3
      SQL and ILE

      How is record locking managed when you externally define the I/O using SQL? For example, do you pass a parm that indicates if the SQL statement should execute a SELECT for READ ONLY or FOR UPDATE? Just curious... Chris

      Comment


      • #4
        SQL and ILE

        All of our programs are in OPM COBOL with embedded SQL statements. We are finally moving toward ILE. I've created modules for direct SELECT, INSERT, and UPDATE statements that are in a service programs and bound to the main program. However, what is the best way to code for declaring a cursor and fetching to build a subfile. Does it make sense to build modules to the declare a cursor, open it, fetch, and close it. Or should I leave that code in the main program. I had hoped to isolate all DB I-O into service programs for easier maintenance. I'm just not sure which approach makes the most sense in this case. Thanks.

        Comment


        • #5
          SQL and ILE

          That you could have two different procedures for declaring cursors. One that declares a simple cursor for read only and a second that declares a dynamic cursor. You could make it one procedure and handle that with an argument. Then include the FOR UPDATE OF ... within the SQL statement itself if desired. Note that FOR UPDATE OF is not needed to make the cursor update capable. The dynamic keyword does that. the FOR UPDATE OF narrows the list of update capable columns to minimize record locking issues. So that two users can update the same record at the same time so long as they do not update similar columns. That's the approach I would take. I hope it helps. Kevin

          Comment

          Working...
          X