Chuck & Alan,
Thanks for the response. I think we're nearing the point where we may start creating files with SQL, and my knowledge of that area has some gaps.
-Kurt
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, June 24, 2009 3:57 PM
To: midrange-l@xxxxxxxxxxxx
Subject: 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
midrange.com
