|
Hans, At 08:25 AM 10/12/99 -0400, you wrote: >Our intention was that in the future, if there were enough demand, >we would possibly provide more support in this area. Perhaps >something like a ALWNULL(*FULL) option. As an aside, I believe that one rule the developers should keep in mind is that any integral feature put into the DB must be easily accessible via all (mainstream?) mechanisms that are used to access data. This would include (but is not limited to) RPG, SQL, Query, Cobol, and dare I say CL. How many people used the date data types before RPG fully implemented them, i.e. when it was a compiler option? I suspect not too many. >The workaround is the brute force approach. For each field declared >internally that you want to treat as null-capable, define an >indicator field that maintains the null attribute. Then, every >time you copy a null-capable field, also copy that indicator value. Please make this as automatic and easy as possible. It seems that other platforms / implementations make null support a lot easier and more intuitive. -mark +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
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.