Blog
i can

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

January 04, 2010

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83545a5d153ef0120a7a281c5970b

Listed below are links to weblogs that reference i Can…Use RPG and SQL Together:

Comments

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.

Thanks,
Ray

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.

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Comments are moderated, and will not appear until the author has approved them.