|
midrange-l-request@xxxxxxxxxxxx wrote: > 3. RE: SQL date comparison - a better way? (rob) > > And, providing your applications do not directly access >the physical file, but only access the logical files, you could add fields >without any level checks. > >I've seen this technique used by a software vendor. I've used the technique with good results although there are a couple items to be aware of. Most importantly, the LFs must be compiled with explicit field lists. Add a new field to the PF and recompile it. The previous LFs can then be recompiled and will not cause level-checks as long as the field lists are unchanged and no significant changes were made to the original fields. New fields shouldn't need to be added at the end of the PF; they can be anywhere -- the original physical order can even change. Also, there generally needs to be at least one program that is recompiled because this program is the one that does the physical updates. When new fields get added to a table, they ought to be accounted for in the primary physical maintenance program. This program would always need to be compiled over the actual PF. While it's certainly possible to have an LF defined for this purpose, the problem remains the same. If data in the new fields will be maintained, the update program needs to include the fields. Ideally, this will only be a single program (or module or service program procedure or...). In a lot of circumstances, this might be minimized by using default values for the new fields. Tom Liotta -- Tom Liotta The PowerTech Group, Inc. 19426 68th Avenue South Kent, WA 98032 Phone 253-872-7788 x313 Fax 253-872-7904 http://www.powertechgroup.com __________________________________________________________________ McAfee VirusScan Online from the Netscape Network. Comprehensive protection for your entire computer. Get your free trial today! http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397 Get AOL Instant Messenger 5.1 free of charge. Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promo=380455
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.