|
I use both. SQL is great for set processing. The performance of SQL to traditional has gotten so that even a dyed-in-the-wool traditionalist tested it and found SQL faster (just not faster enough to make him switch). One advantage of SQL for simple fetches is that if you are supporting multiple versions of the file (like BPCS 405CD and BPCS 8) then the same program can be used by two different divisions and not die of a record format level check. I wonder if an SQL insert or an update provides an easier way to check constraint violations than traditional I/O does? Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com |-----------------------------+-------------------------------------------| | "Bob Cagle" | | | <bcagle@xxxxxxxxxxx> | | | Sent by: | To| | midrange-l-bounces+rob=dek| "Midran| | ko.com@xxxxxxxxxxxx | ge | | | Systems| | 07/22/2004 01:16 PM | Technic| | | al | | Please respond to | Discuss| | Midrange Systems | ion" | | Technical Discussion | <midran| | <midrange-l@xxxxxxxxxxx| ge-l@mi| | m> | drange.| | | com> | | | cc| | | | | | Subject| | | SQL vs.| | | traditi| | | onal | | | I/O? | | | | | | | | | | | | | | | | | | | |-----------------------------+-------------------------------------------| Maybe I'm opening a bucket of worms here, but for straight RPG programming on an AS400/iSeries/i5 machine, why should we use SQL instead of traditional RPG I/O (read, chain, etc.)? I have seen multiple postings on these lists and several articles all saying we need to switch to SQL now! But, traditional I/O works great on the platform it was intended for - the SQL implementations I have seen are 'clunky' at best. Note: I understand SQL has its place; web programming, etc. I just don't see the need to switch over 100% to SQL. What am I missing? Why should I use an SQL select statement versus a simple chain to a logical file? Bob Cagle -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
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.