"Update" of the VIEW with the literal as field is not allowed, since 
there is no way to modify the literal.  Unlike a MFLF which can have a 
FMTSLR there is no way to know where the data would go for an INSERT. 
Instead, INSTEAD OF [update, insert, delete] triggers can resolve that.
The VIEW was created as Read-Only.  The WRKDBF is probably ignoring that 
attribute, and asking the DB2 to update the data anyway.  The DFU should 
report DFU0564 to indicate the read-only case.  Query/400 is read-only 
SELECT, so it will be happy.  As input to Query/400 it is moot that 
there is no longer a key, since even as a keyed LF, that did not ensure 
ordering in a report for a *QRYDFN matched the key -- the query must 
always explicitly specify the order to ensure it.
Regards, Chuck
-- All comments provided "as is" with no warranties of any kind 
whatsoever and may not represent positions, strategies, nor views of my 
employer
Jeff Crosby wrote:
I know that, that's why I very seldom use WRKDBF.
I recreated the file like this:
CREATE VIEW QTEMP/ALITMMST AS (
   SELECT A.*,CAST(00010101 AS NUMERIC(8,0)) AS DLDAT FROM DMITMMST A
   UNION ALL
    SELECT B.* FROM OLITMMST B )
And now DLDAT shows as 8,0.  VIEW and WRKDBF still fail however.
Since it works in query/400 I suppose this should be sufficient as that's
where the buyers use it.  I'd like it to have a key though.
As an Amazon Associate we earn from qualifying purchases.
	
 
This mailing list archive is Copyright 1997-2025 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.