This issue is non-critical but it is driving me nuts.

We have search utility and this is how it works:

Hit .

An input box pops-up.

Type in the first few letters of the name

A popup shows a list of names to choose from.

It has always worked for years. Then, about a week ago, it started lagging behind by one set of search criteria. In other words, I type in 'Sm' and it returns nothing. So, I type in 'Jo' and it returns 52 Smith's. I type in 'Doe' and it returns 23 Jones's. It is always one search behind.

The code:

The code does a BTREE.EXTRACT returning KEYS.

The KEYS are then written to a LISTS file called NAME_LOOKUP.

The popup is based off of LISTS NAME_LOOKUP.

I updated all indexes in the Employee file…still no help.

So, I put a msg box right after the BTREE line and it is returning the correct keys but the (WRITE KEYS ON LIST_FILE, 'NAME_LOOKUP') is not working properly or too slowly.

Has anyone seen this before?

Thanks,

Marty

Have you put an ELSE clause on your

WRITE KEYS ON LIST_FILE, 'NAME_LOOKUP'

line to see if the system is throwing an error?

Is the routine checking the value of Status() to ensure the write was successful?

Is the routine deleting 'NAME_LOOKUP' from LISTS prior to running? This at least would ensure that stale data is not displayed.

Have you considered replacing the static popup definition and using Pop.Up() or Pop.Up.Soft() instead?

[email protected]

Greyhound Lines, Inc.

Generally results like this would be a value mark in a key.

The Sprezzatura Group

World Leaders in all things RevSoft

I did try an ELSE clause but it did not produce anything.

I have not tried STATUS yet because I am not familiar with catching errors in AREV but I can give it a shot.

As far as clearing the record, I did try to WRITE a blank field into KEYS in NAME_LOOKUP then re-pop with WRITE. The result was a search that returned all Employees in the pop up and it was *still* lagging behind by one search. I have not tried to delete the record completely. It might return different results.

I am not too familiar with creating PopUps but it seems relatively easy. I hate to take the time to re-write a process but it might be my only alternative.

It is frustrating because it always worked before and the BTREE is returning the proper data set. I just can not stuff it into the record at the proper time.

A couple of thing that I left out before:

AREV 3.12 on Win98. This is inherited/legacy code.

Thanks for your input.

I guess you lost me. There is a convert statement in the code…

CONVERT @VM TO @FM IN KEYS

… just before it does the WRITE.

Also, by using the msg box I can see the layout of the keys and there does not appear to be anything strange in the list?

I will keep at it.

Thanks.

I figured it out. Matt's suggestion of DELETEREC worked.

Thanks to everyone for the help.

What made it esspecially confusing was the conflict between the Dictionary and the CONVERT @VM TO @FM.

When I did a LISTDICT LISTS it showed 2 fields. The KEY and a DATA field (2 fields total). But, when you do a WRITE KEYS into the NAME_LOOKUP record you must first convert Values to Fields in KEYS which would create multiple new fields on the fly. So, it makes sense to delete the whole rec bcuz you do not know how many fields you are dealing with on the prior search.

Why did it work before without the DELETEREC? I do not know. I am just glad that it is working again.

Thanks,

Marty

I figured it out. Matt's suggestion of DELETEREC worked.

Thanks to everyone for the help.

What made it esspecially confusing was the conflict between the Dictionary and the CONVERT @VM TO @FM.

When I did a LISTDICT LISTS it showed 2 fields. The KEY and a DATA field (2 fields total). But, when you do a WRITE KEYS into the NAME_LOOKUP record you must first convert Values to Fields in KEYS which would create multiple new fields on the fly. So, it makes sense to delete the whole rec bcuz you do not know how many fields you are dealing with on the prior search.

Why did it work before without the DELETEREC? I do not know. I am just glad that it is working again.

Thanks,

Marty

View this thread on the forum...