Re: Record format level mismatch question

Kurt Anderson wrote:

Multiple replies have been made saying that LVLCHK(*NO) is
a bad idea. However it was my understanding (based on my
class with Robert Bestgen) that SQL tables do not trigger
level checks (or is LVLCHK(*NO) under the covers), I forget
the exact phrasing. These tables can of course be used by
embedded SQL or as native I/O.

The SQL TABLE is a database physical *FILE object. Both have a Record Format Level Identifier. A request to DSPFD AnyTABLE *RCDFMT will show the RcdFmt level identifier for the file. In order to enable level checking I even implemented that feature for the SQL VIEW objects; long ago, a request to DSPFD AnyVIEW *RCDFMT would show blanks for every SQL VIEW. The Common Data Management performs the /level check/ feature when requested; i.e. a stored RcdFmt level identifier is passed as part of the Open of the file. The SQL does not ever pass the RcdFmtLvlID on the open request, because the SQL does all of its own mapping and compatibility verification; e.g. if a column is missing, the SQL issues its own message [its sqlcode & sqlstate] specific to that condition.

How is this different?

The difference is the programming interface, not the type of database file; i.e. SQL versus DDS or other creation methods. Use SQL DML instead of non-SQL I/O, then a changed record format level identifier is not relevant.

Vern Hamberg wrote:

You recompile - pure and simple - LVLCHK(*NO) is 99.99%
never to be done.

The use of LVLCHK(*NO) then, applies only to non-SQL opens of database files. For non-SQL opens, if the layout of the database file [its record format] does not match the layout compiled into the program [e.g. its included DS], then the data retrieved by the program [e.g. by READ] may not map properly into the layout defined in the program. When the data does not align properly in the declared variables, then obviously there is a great potential for GIGO. Explicitly ignoring the LVLCHK feature using LVLCHK(*NO) asks the common data management to ignore the difference in layouts between the file and what was declared\stored in the program object. By ignoring the differences, there might be decisions made in the program on Garbage-In and thus the program may effect Garbage-Out. Vern suggests then, that in almost every case, a [non-SQL] programmer would best leave level checking in effect, to ensure a recognizable change would be diagnosed by the error msgCPF4131.

Regards, Chuck