× 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.



FYI

fyi for creating an index:
I'm not sure if this is still true for V5R4, but used to be when a SQL
Index is created it uses a 64K logical page size for its internal binary
radix tree index, compared with 16K for a DDS logical file, and thus from
what I understand provides better query optimization.

In Release V5R4 the page sizes of both SQL indexes AND keyed DDS described
logical files can be set at compile time between 8K and 512K. The default
values for the page sizes stay unchanged, i.e. 64K for an SQL index and 8K
for a DDS described logical file. If a DDS described logical file can share
access path with a SQL index the larger page size of the index get
inherited.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"

-----Ursprüngliche Nachricht-----
Von: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von Billy Rowe
Gesendet: Thursday, April 12, 2007 00:22
An: Midrange Systems Technical Discussion
Betreff: Re: Creating a PF - Compiled File vs. SQL Create Table Command


I can't think of anything that stands out per creating a table by dds or
SQL but as fyi for
creating an index:
I'm not sure if this is still true for V5R4, but used to be when a SQL
Index is created it
uses a 64K logical page size for its internal binary radix tree index,
compared with 16K
for a DDS logical file, and thus from what I understand provides better
query
optimization.

Whoops, that's one place I forgot to check....thanks!

-----Original Message-----
Subject: RE: Creating a PF - Compiled File vs. SQL Create Table Command

Brian,

Did you check the archives? IIRC, there was a lengthy discussion on this
last week. If not, I know there are several threads dealing with this
topic. You will probably find your answers there. If not, let us know
what you couldn't find.

Rick

-----Original Message-----
Subject: Creating a PF - Compiled File vs. SQL Create Table Command

Hi All,

Is there any difference between creating a physical source file member and
compiling it versus using an SQL CREATE TABLE command? When using the i5,
I've always created a PF and then compiled it as my table, but I have never
created a table using the SQL CREATE TABLE command.

I did a test of the CREATE TABLE command, and it did indeed create a PF in
the specified directory. However, it doesn't create the associated member
(or does it?) that I can use to modify and update the table if fields need
to be added/modified/deleted.

One advantage I did notice is that I am not limited to ten characters like
a standard physical file (yes, I understand there are ways around it).

Are there any specific reasons why I would want to select one method over
another? File maintenance would be a matter of editing the PF member and
doing a CHGPF on a modified file versus an ALTER TABLE command.

Am I missing something fundamental here?

Thanks

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.