× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: SQL TABLES vs CRTPF objects
  • From: John Carr <74711.77@xxxxxxxxxxxxxx>
  • Date: Wed, 10 Dec 1997 20:52:30 -0500


RE:     Re: SQL TABLES vs CRTPF objects

I asked Kent Milligan of IBM DB2/400 to once again to settle the discussion.
I just got this reply from him that he was kind enough to offer. 
(My suspicions I think were correct about PF's and TABLES being the same 
internally <John Carr>):


Kent said;

The underlying physical object created by CRTPF & SQL CREATE TABLE interfaces
is identical, but their are a few minor differences in terms of object
attributes.

 The underlying object does have an SQL table tag that is set for files created
with the SQL CREATE TABLE statement (this is displayed on the DSPFD command).
The SQL file object also is only allowed to have one member as your example
showed as well as no maximum size.

SQL file object also use the reuse deleted records option by default.
Journaling is only automatically started on the file if the SQL table is
created in a library/collection when that same library has a journal named
QSQJRN.  Default is to journal both before & after images.

SQL tables have more data validation/correction performed on Insert/Update
operations which allows for slightly faster retrieval since the data was
verified on the way into the object.  Conversely, physical file insert/update
operations don't perform this low-level data validation/correction and insert
perform the data verification on the retrieval operations.  This is a slight
performance difference.



Kent Milligan, DB2/400 Solutions Team
AS/400 Partners In Development

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-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 thread ...


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

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.