[[https://www.revelation.com/|Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community]]
==== IDX_SETS function 4 returned error code -2436????? (AREV Specific) ====
=== At 12 NOV 2004 10:33:55AM Michael Slack wrote: ===
{{tag>"AREV Specific"}}
One of our remote sites has a user that is getting an "IDX_SETS function 4 returned error code-24836" error message. This is on one of our AREV 3.12 applications. I've researched this error on this discussion area and gave my findings to the data support person but they reported that nothing seems to work.
Below is excerpts from some of the E-mails that I've seen on this subject.
*******
This happened while importing labor... what do you think? EEK!
IDX_sets function 4 returned error code-24836
FS4487 FATAL INTERNAL ERROR
This happened after Joni rebuilt the LABOR_ALLO_MSTR indexes and then let the users back in.
It only happens to her. I can run this just fine. Her expanded memory is active so it isn't that.
I can't run the report on her machine and she can't run the report anywhere. It hangs for a long time and then she gets the error.
I'm totally clueless. Apparently this started when Chad did something to her machine this past spring.
*******
Let me try to explains some of this.
"importing labor", labor information is entered thru a data entry/update window into a table within the application. At some point the user processes (imports) the data into our master table. Along the way it may update other tables such as the amount of time on a work order or the amount of time a particular piece of equipment was ued. So it's not a true import. We've been using this process for years without any problems and especially without this kind of error.
"let the users back in", we have a process where we can forcefully log out all users within the application and keep them out while some process is run that would otherwise cause problems if users were to be using the application. Such as rebuilding indexes on a very large table like our LABOR_ALLO_MSTR table. This same process is used to aloow the user to log in again normally. This process has been around for years and has not been modified in a long long time.
"Apparently this started when Chad did something to her machine this past spring." The remote location is seaonal, so between the time "Chad" (a PC Tech I assume) did something to this particular machine and it resently started having these troubles, it could very well have been sitting idle. Or at least not being used to work on the AREV application the this user is currently having problems with.
I'm assuming that with a name like IDX_SETS that this has something to do with indexing. The Data Management Specialists here and at our remote location have tried things like refreshing the indexes, rebuilding the indexes, removing and redfining the indexes from scratch on this table. But so far nothing seems to have helped.
Can anyone point me in the right direction? Any help would be appreciated.
Thank you for your time.
Michael Slack
----
=== At 12 NOV 2004 11:09AM Matt Sorrell wrote: ===
Michael,
I think I have seen this when there is a space issue at DOS. I would check what the settings are for the temporary sort path and the rollout path. Then, verify that the disk quotas (if any) and available space for this user on those directories is sufficient.
The system creates files at DOS when rebuilding the indexes, and it could be running out of space on the file system.
HTH,
msorrel@greyhound.com
[url=http://www.greyhound.com]Greyhound Lines, Inc.[/url]
----
=== At 15 NOV 2004 03:21PM Michael Slack wrote: ===
Thanks Matt for the suggestions. I've passed them along to our AREV administrator at our remote site. I sent the administrator a detailed instructions on what to look for and where to look. I've yet to hear back from them but I'm keeping my fingers crossed they'll find the problem and be able to fix it.
Again, Thanks,
Michael Slack
[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=B417A7ED331491E785256F4A005580BC|View this thread on the forum...]]