Do you know if this is still a problem (too busy to trawl through the readme
files)?
Thanks
David
Kevin King-2 wrote:
Come to find out the problem was that the user never logged off.
Apparently
Unidata keeps some information about indexes in the file buffer and
because
that file buffer
:28 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Unidata Indexing Problems
Do you know if this is still a problem (too busy to trawl through the readme
files)?
Thanks
David
Kevin King-2 wrote:
Come to find out the problem was that the user never logged off.
Apparently
Unidata keeps
Come to find out the problem was that the user never logged off. Apparently
Unidata keeps some information about indexes in the file buffer and because
that file buffer was open at the time we rebuilt the index, that session
didn't see the new indexes we had created. Once that user had logged
We have a customer firmly ensconced on Unidata 5.1 on HP-UX (i.e. upgrading
is not an option at this time) who is experiencing a strange indexing issue.
We created a regular Unidata index (CREATE.INDEX) on a normal data field
(attribute 189), built the index, tested, all is well. Another process
Check the release notes. I recall there being a problem with the sort.exe
program on (I thought) a later version of UD 5 (5.2.4?) on windows. Same
symptoms. Fix was to upgrade workaround was to grab the exe from a later
version (6.0.12) and use it. Definately run it past support before you try
That's not a naive question at all. I'll try and answer it. Creating an
index on MY_FIELD will probably speed things up. It depends on the
cardinality of the data and how many null values there are. For example,
if this is a large file, say 10,000,000 records, and MY_FIELD contains
In a message dated 6/7/2005 6:37:39 AM Pacific Daylight Time,
[EMAIL PROTECTED] writes:
For your specific question about nulls, it depends on how many nulls you
expect to find. Using the above examples, if you only expect a handful of
null values, your select statement should work the
On Tue, 7 Jun 2005 [EMAIL PROTECTED] wrote:
I think we have to keep in mind what happens in the whole process.
While the select itself will process faster (provided you have not specified
NO.NULLS when creating the index), we have to ask what you're going to do next
with that list ?
If the
I've got a naive Unidata question, but figured I'd throw it out there
anyway. In short, does indexing a field in a given file help performance
when querying for an empty string? ie:
SELECT MY_TABLE WITH MY_FIELD=''
I've always assumed yes but would like to hear other's thoughts.
Jeff Butera,
