i can

Dawn May

Dawn May

Bookmark and Share

October 2014

Sun Mon Tue Wed Thu Fri Sat
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

« i Can … Identify Your Server Jobs | Main | i Can … Automate Monitoring With Watches »

January 04, 2010


Would be nice to have table sensitive commitment control with SQL. But CC is automatically started by the ILESQL environment and there is no way to control it on table level. Imagine you have a log file... If you decide to rollback due to an error the log info will vanish as well.

The COMMIT that is specified on the CRTSQLRPGI command is the commit level for all SQL statements in the program. You are right that we do not have a way to control it on a table level, but you can control it on the statement level.
The isolation-clause on some SQL statements lets you override what was specified on the COMMIT parameter.

exec sql insert into logtab values(1, 'abc') with NC;

If you use dynamic SQL, the clause can be added to the prepare statement in the attributes string.

The SQL Reference has information about the isolation-clause and the SQL programming manual has a section on commitment control.

Please identify the advantages of RPG embedded SQL over Stored Procedures.

This would be very helpful. .Net programmers don't understand and will not listen to us saying that embedded SQL in RPG has performance advantages when accessing data on the i5.


Performance wise, they should be close to the same. But keep in mind there are different advantages to each. SQL stored procedures are portable to other platforms. Embedding SQL in RPG allows you to call APIs, use /COPY for common code, and other RPG features.

COMPILEOPT DBGVIEW will not work as it is defined on the CRTSQLRPGI command.

The CRTSQLRPGI command does not have the same parameters as the compiler commands, CRTBNDRPG and CRTRPGMOD. We only add parameters to the CRTSQLRPGI command if the value is something that SQL will need to know. This required some programmers to do a two step compile, which is calling the precompiler command followed by calling the compiler command. We added the COMPILEOPT parameter to the CRTSQLRPGI command so that a two step compile is no longer required. The string in the COMPILEOPT parameter needs to be a compiler parameter name and value as how you type it on the command line. The precompiler will concatenate the COMPILEOPT string to the command that it generated. In the Embedded SQL Programming manual, there is a section titled “Compiling an ILE application program that uses SQL” that lists the parameters the precompiler passes. If DBGVIEW(*SOURCE) is specified on the CRTSQLRPGI command, then DBGVIEW(*ALL) is specified on both the CRTRPGMOD and CRTBNDRPG commands. So if you want DBGVIEW with the value of *LIST in the COMPILEOPT parameter, you must have DBGVIEW(*NONE) and COMPILEOPT('DBGVIEW(*LIST)') specified on the CRTSQLRPGI command.

Any Idea how to specify precompile option *CVTDT inside the program.

There is not a way to do it inside the program. It must be specified on the command.

The comments to this entry are closed.