On 1/26/11 10:11 AM, Jeff Buening wrote:
Thanks Chuck and Micheal,

While I am not the Chuck to whom the reply was made from the digest, I had also provide a response which effectively answers affirmatively, each question posed in the quoted text. Inline to the quoted message is further reply and a link to my prior response that is on the archive but which maybe did not hit the email list.

So issues with performance would be more on my decision of when to
use SQL or Traditional I/O or how I use them?

I would expect that; as alluded in a prior reply:

Whether the data is on a DDS or DDL defined file is not the issue?

Typically whether the data resides in either DDS-PF or DDL-PF is of little significance\consequence for performance. When there are constraints and RI added, those can be much more consequential esp. for join, but for which a PF from DDS would need to be limited to having MAXMBRS(1) by either CRTPF or CHGPF.

So, yes we possibly would see better performance by moving to DDL or
using INDEX, but until then that shouldn't stop me from using SQL in
my programs when I feel useful?

Yes, use SQL for data access whenever that seems a reasonable fit, irrespective of the means for having created the database table\file and any index\access-path.

However the choice of DDL for INDEX over DDS for LF is much more likely to be beneficial to the SQL than the choice of DDL for TABLE over DDS for PF. Also note that the use of some features [e.g. UPPER scalar function or shared weight sort sequences on older releases] or by specification of a non-VIEW logical file may limit a SQL query to run using the CQE [Classic Query Engine] which may not perform nearly as well as a SQL query which can run using the SQE [SQL Query Engine].

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2021 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.