× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.