On 26/10/11 00:23, Steve Romanow wrote:
I reread my post and meant no disrespect Wols. I shouldnt post replies
without considering twice.
No worries Steve. I shoot from the hip sometimes too - it can be
embarrassing :-)
Cheers,
Wol
___
U2-Users
-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Dave Laansma
Sent: Tuesday, October 25, 2011 4:59 PM
To: U2 Users List
Subject: Re: [U2] UniBasic Question
Unless you know the keys to the records you're selecting, even the
EXECUTE SELECT ... is going to have
Can anyone help explain this behavior or offer a workaround that saves me
from handling it with line counters and printing my own
headings?Cheers,Kebbon
___
Perry's approach is the correct one. If you want to
And... when you prematurely quit from an execution level which *had* been
processing a select list your select list is not thrown away.
Which is annoying.
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
grabs both the key and record, due to the construct of the
database.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson
Sent: Tuesday, October 25, 2011 4:08 PM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2
Dave
The next-to-last one may depend on Unidata vs. Universe. I understand
that Unidata only 'fetches' the key in the READNEXT while I believe
Universe grabs both the key and record, due to the construct of the
database.
I believe that is the case in Unidata. A SELECT returns a list of
, October 25, 2011 4:53 PM
To: U2 Users List
Subject: Re: [U2] UniBasic Question
Dave
The next-to-last one may depend on Unidata vs. Universe. I
understand that Unidata only 'fetches' the key in the READNEXT while
I believe Universe grabs both the key and record, due to the
construct
Unless you know the keys to the records you're selecting, even the
EXECUTE SELECT ... is going to have to read each record, how else
would it know which records to throw out?
SELECT is definitely faster than EXECUTE SELECT... and I try and use it
first.
Charles Shaffer
Senior Analyst
I don't know if I agree that SELECT is faster. If you are using
indexed fields, SELECT is definitely not the good choice.
On Tue, Oct 25, 2011 at 5:14 PM, charles_shaf...@ntn-bower.com wrote:
Unless you know the keys to the records you're selecting, even the
EXECUTE SELECT ... is going to
I don't know if I agree that SELECT is faster. If you are using
indexed fields, SELECT is definitely not the good choice.
Are you saying that when there is an index, the system does not need to
read the record at all? It just gets the SELECT list from the index? Is
this only true in
with only a slight difference.
BobW
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of
charles_shaf...@ntn-bower.com
Sent: Tuesday, October 25, 2011 2:14 PM
To: U2 Users List
Subject: Re: [U2] UniBasic Question
Unless you know
True on UV, too.
Compare output of these using EXPLAIN keyword:
LIST FILE WITH indexed_field = soemthing EXPLAIN
LIST FILE WITH indexed_field = soemthing EXPLAIN NO.INDEX
Or forget EXPLAIN, but do it with a large file and notice the speed
differnce.
On 10/25/2011 4:29 PM,
Add a second selection criteria and the benefit of the index is washed
out.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles
Stevenson
Sent: Tuesday, October 25, 2011 2:39 PM
To: U2 Users List
Subject: Re: [U2
criteria and the benefit of the index is washed
out.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles
Stevenson
Sent: Tuesday, October 25, 2011 2:39 PM
To: U2 Users List
Subject: Re: [U2] UniBasic
Yes yes and no.
If you execute a SSELECT on an indexed field, and don't specify NO.INDEX and do
NOT refer at all to any other fields in the file, then index does NOT read the
record to see if it even actually exists. It just retrieves the list of keys
from the index.
If you specific a
Of Charles
Stevenson
Sent: Tuesday, October 25, 2011 2:39 PM
To: U2 Users List
Subject: Re: [U2] UniBasic Question
True on UV, too.
Compare output of these using EXPLAIN keyword:
LIST FILE WITH indexed_field = soemthing EXPLAIN
LIST FILE WITH indexed_field = soemthing EXPLAIN NO.INDEX
Or forget
But you are potentially reducing your input set for the 2nd criteria
by a large margin correct?
I've never considered alt key + non-indexed usage to create disk thrash.
When you select on an alternate key index, you are reading the file,
but (in Udt at least) an X_myfile binary file. So you are
of the index is washed
out.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Charles
Stevenson
Sent: Tuesday, October 25, 2011 2:39 PM
To: U2 Users List
Subject: Re: [U2] UniBasic Question
True on UV, too.
Compare output
like the way the records are layed on the disk.
That causes thrashing.
-Original Message-
From: Steve Romanow slestak...@gmail.com
To: U2 Users List u2-users@listserver.u2ug.org
Sent: Tue, Oct 25, 2011 3:07 pm
Subject: Re: [U2] UniBasic Question
But you are potentially reducing your
@listserver.u2ug.org
Sent: Tue, Oct 25, 2011 3:08 pm
Subject: Re: [U2] UniBasic Question
RetrieVe will use an index if it can, regardless of the order of the
election criteria ( if not select list is already active).
etrieVe will now do intersections of index reults if 2 indexed
election criteria
On 25/10/11 22:22, Steve Romanow wrote:
I don't know if I agree that SELECT is faster. If you are using
indexed fields, SELECT is definitely not the good choice.
SELECT *is* faster. Because it does far less work!
EXECUTE SELECT needs to read the entire file to create a select list.
SELECT
Consider a sparse file. I have seen where a execute select is faster so I
counter your AlwaysFaster claim. Like the previous poster said, it will
always be fastest to start, but not always first to complete.
On Oct 25, 2011 7:00 PM, Wols Lists antli...@youngman.org.uk wrote:
On 25/10/11
I reread my post and meant no disrespect Wols. I shouldnt post replies
without considering twice.
On Oct 25, 2011 7:00 PM, Wols Lists antli...@youngman.org.uk wrote:
On 25/10/11 22:22, Steve Romanow wrote:
I don't know if I agree that SELECT is faster. If you are using
indexed fields,
Is this unibasic doing an execute and the 'report' done using a List command
?
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kebbon Irwin
Sent: 24 October 2011 16:13
To: u2-users@listserver.u2ug.org
Subject:
the behavior?
From: syme...@gmail.com
To: u2-users@listserver.u2ug.org
Date: Mon, 24 Oct 2011 16:20:10 +0100
Subject: Re: [U2] UniBasic Question
Is this unibasic doing an execute and the 'report' done using a List command
?
-Original Message-
From: u2-users-boun
.
Perry
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Kebbon Irwin
Sent: Monday, October 24, 2011 9:29 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] UniBasic Question
The subroutine does an execute 'Select
Kebbon:
I've converted our application from D3 to UniData. There were a number
of issues with the Heading statement and, if I remember correctly,
wouldn't allow me to do what you're trying. Fortunately, we already had
a scrolling program to pass output into so this didn't cause problems.
27 matches
Mail list logo