I like to *think* that I have seen just about all the warts in Arev but here is a new one to me .. (both systems are 3.1)

System 1:

On a file with an index on date ..

SELECT FILE WITH DATE=1.1.04'

will update index then retrieve all data for that date

if I

SELECT FILE WITH DATE ] '1.1.04'

it does not look at the index but instead searches the file.

System 2: (different copy of arev)

Both selects use the index ..

SO .. any ideas on what could be causing this?

[email protected] onmouseover=window.status=the new revelation technology .. a refreshing change from the dark side;return(true)"

DSig's Radio Free Oregon

David Tod Sigafoos

SigSolutions, Inc.

Check the ICONV / OCONV and the justification on the date field in the dictionary? Are they the same? Are both real fields (not symbolics)? Are you holding you mouth the same way each time?

wow .. somebody finally responded .. this must be the WORKS

they sure seem to be the same. And there would be a big difference in selection if the I?O were different between the system.

Like I said .. on both ..

select file with datefield=01/01/04'

work correctly. it is just the range bit that it doesn't see the index.

but that is what i get from a response from down under

coming to NO?

[email protected] onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"

DSig's Radio Free Oregon

David Tod Sigafoos ~ SigSolutions

Actually looking back I don't see that I mentioned that=works

The 'bad' arev will only use indexes if you=a date. you can do multiple like

select file with date=12/12/04' or with date=12/13/04'

that works .. but any time using anything other than=.. no indexes

[email protected] onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"

DSig's Radio Free Oregon

David Tod Sigafoos ~ SigSolutions

Generally symptomatic of a conversion issue but why?…

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

it is happening in all tables for all fields indexed of type date.

One field with output of D2/ and one with D4/ both have the problem. and as I think i mentioned .. ALL date fields are this way. Haven't checked any other type of conversion.

[email protected] onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"

DSig's Radio Free Oregon

David Tod Sigafoos ~ SigSolutions

I think our Arev systems must be communicating using some unknown quantum connection!

Our 3.12 system has in the last month exhibited the same kinds of issues. Specific date (or name) selects will find the data using the indexes. Ranges using GE, GT, BETWEEN, etc. do not use the indexes.

We have found that the only way to fix the issue is to remove the index, and then during the re-add change the index from CASE_INSENSITIVE to CASE_SENSITIVE. Removing and re-adding with the change in sensitivity does not fix the problem.

Recently we have been requiring the use of data types on all fields. Could the addition of a data type to an index field that previously had none (not VARCHAR just no data type at all) cause this?

Ralph,

Date field:

so I deleted the index and reapplied. No Joy

I deleted the index and reapplied with sensitivity set and JOY!!!

so I deleted again and reapplied without and NO Joy ..

So what is going on with this? Is this an old problem with 3.1?

[email protected] onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"

DSig's Radio Free Oregon

David Tod Sigafoos ~ SigSolutions

Do we know what 'triggers' the indexes to stop working after they have been working?

Is it adding a Data Type? Or something else?

We have arev tables which approach the 2GB and where it not for a nightly archiving process, would exceed it. I certainly don't want to trigger an index to not working on one of these babies!

Help us Mister Wizards! (Pat? Mike? Andrew? C?)

View this thread on the Works forum...