Re: user record updates, locking, and logical vs physical record access

On 08-Aug-2016 21:40 -0500, MichaelQuigley wrote:

I have one other word of caution when dealing with logical views
having a limited set of fields from the physical. Be very careful if
you use them in a program that adds records. The fields which are not
included in the logical will get the database defaults.

Only if a default is [explicitly or implicitly] defined, else the I\O would fail; IIRC, the VIEW might even be established as read-only per the Allow Write (ALWWRT) [alternatively: Allow Insert (ALWINS)] attribute being set-Off. Note: The implicit default is referred to as the data-type-default; that can be different between DDS and SQL, notably, if only, data-types including a date.

Without review of what those default values would be, you can end up
with some corrupt or erroneous data--and sometimes that won't show up
for quite some time.

Indeed, poorly designed database files can produce undesirable results in that scenario; and data errors are far too often realized only long after, and seemingly, even at the most inopportune times.

Yet, just to be sure readers understand, that effect of the default would be neither /corrupt/ nor /erroneous/ data values, from the perspective of the DB; i.e. the omitted column should be /expected/ to be set to the specific default-value that was assigned\defaulted for the column of the physical file\table either when the file was originally created or when the file was last altered to establish a different DEFAULT. And, of course, the field\column default plays no role in the record update discussed from the OP; only an impact on the write\insert as additionally discussed in the followup reply quoted here.