Direct access to an index and its keys

I have a requirement to provide a list of all the distinct keys in an
index and the number of occurences of each key. At the moment I open a
table, set the appropriate index and in a 'while not table.eof' loop I
compile a list of keys and their number.

I'm assuming that while this is going on, all the records in their
entirety are coming across the network from the server so, on a slow
network there's a massive overhead just to get at the index keys.

Is there a more effivicient any way of getting at an index and its keys?

Dave

> Is there a more effivicient any way of getting at an index and its
> keys?

SQL.

--
Eivind Bakkestuen [NDD]
Nexus Database Systems

Eivind Bakkestuen [NDD] wrote:

> > Is there a more effivicient any way of getting at an index and its
> > keys?
>
> SQL.

By which you mean e.g. select column1 from table order by column1 ?

Unfortunately I over-simplified the question and therefor got a good
answer but to the wrong question. What I neglected to mention is that
the index in question is produced by our modified server that can build
an index on the content of a blob field (XML) based on an XPath
expression..

So if the blob looked like

<record>
<some_content>Mary had a little lamb and a little beef</some_content>
</record>

and we had in index which was defined to index the text returned by
applying the XPath /record/some_content/text() to this record. The
record would appear in that index five times with keys Mary, had,
little, lamb and beef (some common words are skipped I believe)

Given the above, SQL cannot help. What I was hoping for (dreaming of)
was some way (from the client) of getting at just the keys within an
index.

Clearly the question is asked in blissful ignorance of how indexes are
stored or whether they can be accessed without accessing the connected
records at the same time.

Dave

Dave Sellers wrote:

> Clearly the question is asked in blissful ignorance of how indexes are
> stored or whether they can be accessed without accessing the connected
> records at the same time.

Not outside some places deep within the server engine.

Thorsten Engler [NDA] wrote:

> Dave Sellers wrote:
>
> > Clearly the question is asked in blissful ignorance of how indexes
> > are stored or whether they can be accessed without accessing the
> > connected records at the same time.
>
> Not outside some places deep within the server engine.

Thanks Thorsten, I suspected that would be the case.

Dave

Thorsten Engler [NDA] wrote:

> Dave Sellers wrote:
>
> > Clearly the question is asked in blissful ignorance of how indexes
> > are stored or whether they can be accessed without accessing the
> > connected records at the same time.
>
> Not outside some places deep within the server engine.

Hi Thorsten

Having mulled this over for nearly two years, I've plucked up the
courage to return to this. What I would like is some method of a
TnxTable that I can pass a TStringList into and have it filled with the
distinct keys of the current index taking into account any
ranges/filters currently in place.

Can you give a few pointers as to where I might start? I know it's a
terribly vague question but the nexus source is a scary place for us
mortals so any clues gratefully received.

Cheers
Dave

Dave,

| Having mulled this over for nearly two years, I've plucked up the
| courage to return to this. What I would like is some method of a
| TnxTable that I can pass a TStringList into and have it filled with
| the distinct keys of the current index taking into account any
| ranges/filters currently in place.

Perhaps I don't really understand what you're getting at, but,... <g>

If you had, for instance, a component (grid, etc.,) that was subject to
the index-range-filter, then the relevant fields in ANY record that is
"visible" in that component satisfies your requirement. Should be easy
to extract the relevant fields into a "string" or whatever.

Or am I missing something? <g>


--

Q

04/12/2012 11:04:36

XanaNews Version 1.19.1.278 [Q'sBrokenToolBar]

[RichardLight]

I think I can see a way forward with this, but would appreciate a bit of help.

One thing we want to do is an efficient "contains" search. It occurs to me that this could be implemented as a key filter. The key filter is created with the substring to match and a "case sensitive?" boolean property, and then it returns true or false depending on whether the key string contains the match string.

All very straightforward, but it requires access to the key string. I can see that this probably uses the filter engine's FieldsSource property, but I don't know what command/syntax to use to get at the key value, when the buffer passed to the filter engine contains an index key. Any pointers?

Thanks,

Richard Light

Dave Sellers wrote:
> Eivind Bakkestuen [NDD] wrote:
>
>>> Is there a more effivicient any way of getting at an index and its
>>> keys?
>> SQL.
>
> By which you mean e.g. select column1 from table order by column1 ?
>
> Unfortunately I over-simplified the question and therefor got a good
> answer but to the wrong question. What I neglected to mention is that
> the index in question is produced by our modified server that can build
> an index on the content of a blob field (XML) based on an XPath
> expression..
>
> So if the blob looked like
>
> <record>
> <some_content>Mary had a little lamb and a little beef</some_content>
> </record>
>
> and we had in index which was defined to index the text returned by
> applying the XPath /record/some_content/text() to this record. The
> record would appear in that index five times with keys Mary, had,
> little, lamb and beef (some common words are skipped I believe)
>
> Given the above, SQL cannot help. What I was hoping for (dreaming of)
> was some way (from the client) of getting at just the keys within an
> index.
>
> Clearly the question is asked in blissful ignorance of how indexes are
> stored or whether they can be accessed without accessing the connected
> records at the same time.
>
> Dave
Have you looked at Rubicon for this application ... full text indexing
of your blobs?

David Guest wrote:

> Have you looked at Rubicon for this application ... full text indexing of
> your blobs?

Dave is already using the built-in fulltext indexing of NexusDB. His problem is
not with the fulltext indexing, it is with getting a list of keys from these
indices without accessing the full records.