|
Hit my head against a wall for three hours today, so thought I'd bring it to the list to try to save someone else time.
I have a physical file with (among others) fields OZLIB and OZOBJ. These are the library name and object name, and both are defined as 10A. Declaring a cursor like this: SELECT OBJLIB, OBJNAME from TABLE(OBJECT_STATISTICS('MYLIB', 'ALL')) works wonderfully as long as I do FETCH NEXT FROM C INTO :OZLIB, :OZOBJ. But as soon as I stick those two fields (OZLIB amd OZOBJ) into a data structure, I get the dreaded "unusable" message telling me that a subfield doesn't match.
Well, after a whole lot of hair-pulling, I figured it out. The fields in OBJECT_STATISTICS are defined as VARCHAR, and while embedded SQL will convert VARCHAR to fixed-length if you specify individual fields (albeit with a warning at runtime about potentially poor performance), it won't do so on a data structure. The matching rules are much stricter, probably because it assembles the data from SQL and then moves it as a single block of memory into the data structure (although I'm guessing there).
Anyway, since I don't plan to standardize on VARCHAR fields in my databse, my workaround is to do all the fields individually. When I have time I'll try defining the fields with the same name but with VARCHAR in a qualified DS and then try an EVAL-CORR.
As an Amazon Associate we earn from qualifying purchases.
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.