Alpha Warning box "Not an open Index"

[Mike Cameron]

As usual thank you for any assistance you may be able to offer, I am lost on this one. Naturally I had not had this problem when at the conference and expert help was near by.


Has anyone else had a run in with this error box. A search here does not show anything releated to this.

This one has me stumped. When I attempt to change a single character field called "Status" from being blank to a "W" or a "Y" I can get away with doing this once or twice but when on about the fourth record in a row it will pop up that error message and it will continue to do it on every record you attempt to change.

I have had this happen in a form with an embedded browse, so I tried it just in a form, no luck and then it even does it in the default browse.

I am not sure what more info may be needed to figure this one out but I am certainly hoping that someone has a clue.

Thanks
Mike Cameron

[Stan Mathews]

RE: Alpha Warning box

Mike,

Alpha's error messages can be cryptic as you are finding out. The hardest to decipher are the ones returned as a "best fit" answer to the error at hand.

The best advice is to try the data change in the default browse and you have done that. This indicates that it is not a form or browse action problem but probably occurs at the table level. I would check the table field rules and table calculated fields containing lookups, if any.

[Mike Cameron]

RE: Alpha Warning box

Thanks for your reply Stan I really appreciate it since I have a whole department at a stand still cause of this one, I will check the field rules again but they are pretty basic ones with only one conditional look up field which fills a number of this tables fields and one auto increment field for a workorder number. I am wondering if the auto increment field rule might play a part since it is set to increment when a "W" is placed in the field that is causing the error code when it is changed.

Mike

[JerryBrightbill]

RE: Alpha Warning box

Mike,

It sounds like you may be on to something. Autoincrement is done automatically by Alpha when a record is saved. There is really no other way to "force" an autoincrement unless you create you own form of autoincrement. If you have other field rules attached to the autoincrement, Alpha may be trying to find an "index" that doesn't exist. This message usually occurs when you reference a non-existant index in a script or activity.

Jerry

[Bill Warner]

RE: Alpha Warning box

Jerry's right, in that the error means you're trying to do something that references an index that doesn't exist. I get this fairly often, usually because I misspell the index.

You also mentioned that you have a lookup. Keep in mind that lookups also use an index. Since your lookup is conditional, that might explain why yours works a little.

Try updating your indexes (especially in the table that is being called by the lookup), and see what happens.

[JerryBrightbill]

RE: Alpha Warning box

To add to what Bill said, it is easy to delete the index alpha creates for the lookup if you don't know why it is there. To recreate, open field rules and resave the field rules. This should rebuild the index.

Jerry

[John Gamble]

RE: Alpha Warning box

Mike
This sounds suspiciously like a similar reported problem experienced by many others , myself included. If you exit Alpha & return does the lookup work a for a while? If yes this may be the same bug which has been discussed on the board more than once. I have an application which does the same. Sometimes hitting "Enter, left arrow, enter" repeatedly will bypass the error. Otherwise exit & return. Someone has previously posted a workaround on this board which I believe involved seting up a counter and a refresh of some sort after so many lookups. Best of luck

John

[Mike Cameron]

RE: Alpha Warning box

Hi John

Yes you are describing the symptoms to the letter. In my case the lookup always works as it is supposed to mainly because the lookup is done at the point of data entry. It is when I change a record that the problem happens almost exactly as you describe.

I will post what I have found today in the next reply. Thanks for your input.

[Mike Cameron]

RE: Alpha Warning box

Well thanks to all of your suggestions, I believe I am on the right track to resolve the problem but I am not pleased with how I had to do it. Here is where I am at now. Sorry I don't know of a short way to explain this. I will know more after the employees use the application, if it is successful or not but I think it is.

The following expression was in the field rule for a field called "invoice_no".

LOOKUP("options.dbf",'.t.',"invoice_no")

The purpose of this was to always bring in a 4 digit numeric number from "options.dbf" and save it in the current table field called "invoice_no". If I entered a "W" in a field called "status", either during data entry or in change mode, the field rule for a field called "workorder", would increment "invoice_no" by 1 and store the new number in "workorder", that field rule was:

If(status ="W",invoice_no +1,0)

Also in the field rule for "workorder" was a post rule that would post the current value back to the "options.dbf" field of "invoice_no" if a "W" was in the "status" field.

Well I removed all these field rules and used the app without them because I thought that was where I was having the index problem. After removing all this code I could not make the error code come up anymore.

So to help me limp along I have made the field "workorder" an autoincrement field, which means during data entry every record is assigned a unique number even though I may never have a workorder associated with that record. I think this will work but it is less than desireable.

I had table1 going to "options.dbf" and getting the number so that I could allow the employees to reset the start number at the end of each year and I did not have to get involved.

Any ideas on an easier way to have a conditional incrementing numeric field.

Thanks again to everyone and sorry for the long post.

[JerryBrightbill]

RE: Alpha Warning box

Mike,

What you are trying to do sounds like it should be placed on a record event, like CanSaveRecord, rather than as a field event or as expressions to create a calculated field. Using a form event usually is more reliable for multiple operations since each action only happens once when the record is saved.

The concept goes something like this. Select what event you want to use. To get to them, select events on the field rules tab, scroll up to the table name, and select the one you want. If the calculations will be sent to a field in the table, use the CanSaveRecord event since this fires before the record is saved. If you need to send values to another table, use the OnSaveRecord event.

In the event code, first get your lookup value. Then add whatever you want to create the new "autoincrement" value. Instead of a post, open the other table and save the new value.

This is a simplifed explanation, but it should give you the general idea.

Jerry

[Tom Cone Jr]

RE: Alpha Warning box

Mike,

There are several good discussions of alternatives to the field rule autoincrement function. I presently use a hand crafted approach which stores the last value used in a simple text file. the text file gets read and incremented whenever a new record is started. The user can 'reset' the starting number using a simple routine I've made available to them in the application.

-- tom

[Mike Cameron]

RE: Alpha Warning box

Tom that sounds very close to what I would like to acheive. Could you share a little more info on how you do that or the type of code you used, to lead me down the right path.

Thanks

Mike Cameron

[Antonio Wiesner]

Not an open index

Some months ago we had a discussion on a problem that can be described as a "crash" after entering eight records via a lookup table. You can review several posts sent 06-01-2001 to 06-06-2001 including my message 42528, where I described a workaround script with a counter and index update.
For some unknown reason the problem does not appear anymore in our application, and the script is thus unnecessary, but I am still curious about this apparent bug that can cause real trouble.

[Tom Cone Jr]

RE: Not an open index

I recall the thread, and I think we concluded that in some settings filtered field rule table lookups were not stable.

-- tom

[Tom Cone Jr]

RE: Alpha Warning box

Mike,

Bill Warner has a thread in the Code Archive that is similar to what I do. He uses a table to hold the last used value. I'm using a text file, and have to convert it from text to numeric before incrementing it, so his approach would be easier to start with.

Go to the code archive. Search for 'increment' and look for Bill's example.

-- tom