Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
"File already open" error when reindexing 2
- Thread starter orechet
- Start date
A few questions first:
If on a network or accessing remotely, do you have the file permissions to both read and write? (Will it reindex locally but not on the server?) Sounds silly to ask, but in some other programming languages that message has been a rights issue.
Is the table opened exclusively?
Are you sure all the data in the table's fields that get indexed are valid? If there are non-ASCII charaters in the indexed fields such as any character values below 32, this can mess up indexes. Especially troublesome are the nulls, CHR(0).
Okay, lets walk through the replacement of indexes in the MDX:
USE <tablename> EXCLUSIVE
Repeat this step until all TAGs are removed/deleted:
DELETE TAG TAG(1)
Now, the MDX should no longer exist. For good measure, lets USE he table all over again
USE <tablename> EXCLUSIVE
Now recreate each index, as many as needed:
INDEX ON <fields> TAG <indexname>
Did it work? If not, then try copying the records to a new table, perhaps something is scambled in the original table:
USE <tablename> EXCLUSIVE
SET DELETED OFF && do this to preserve any deleted records
COPY TO <newtable> WITH PRODUCTION && new table/indexes
Let us know what works... dbMark
If on a network or accessing remotely, do you have the file permissions to both read and write? (Will it reindex locally but not on the server?) Sounds silly to ask, but in some other programming languages that message has been a rights issue.
Is the table opened exclusively?
Are you sure all the data in the table's fields that get indexed are valid? If there are non-ASCII charaters in the indexed fields such as any character values below 32, this can mess up indexes. Especially troublesome are the nulls, CHR(0).
Okay, lets walk through the replacement of indexes in the MDX:
USE <tablename> EXCLUSIVE
Repeat this step until all TAGs are removed/deleted:
DELETE TAG TAG(1)
Now, the MDX should no longer exist. For good measure, lets USE he table all over again
USE <tablename> EXCLUSIVE
Now recreate each index, as many as needed:
INDEX ON <fields> TAG <indexname>
Did it work? If not, then try copying the records to a new table, perhaps something is scambled in the original table:
USE <tablename> EXCLUSIVE
SET DELETED OFF && do this to preserve any deleted records
COPY TO <newtable> WITH PRODUCTION && new table/indexes
Let us know what works... dbMark
- Thread starter
- #3
Thx, dbmark. Rebuilding the mdx didn't do the trick, so I'm guessing the problem is some rogue character in the table, as you proposed. The problem is, there are over 8,000 records, and I don't know how to go about looking for that character. It's been over ten years since I was a dBASE programmer (this is part of a program that I wrote in 86 and the client hasn't updated since then...)
I'd appreciate any other suggestion you might have.
I'd appreciate any other suggestion you might have.
Does this problem show up on one workstation but not another? If so, see thread290-84526 - "File already open" error (CPU too fast!)
When you determine your solution, please reply so we know you are okay and also others can benefit too.
dbMark
When you determine your solution, please reply so we know you are okay and also others can benefit too.
dbMark
- Thread starter
- #6
Hi, dbmark. I neglected to mention in my first posting that this app is written in dBASE IV. I don't remember (I wrote that app in the early 90s) whether this version of dBASE supports UDFs, but I'm pretty sure it doesn't. It's been years since I did any work in dBASE.
You can find it here, and if it ever changes then I will change the name under the "Posted By" link:
-
1
- #8
Hi orechet,
I have had this error in the past and think it is likely to be the speed of the Pc that is the issue. IIRC dBase uses the clock speed to assign temporary file names and if th clock ticks over too quickly then these become corrupt.
You need to slow your PC down, I did find a utility called IDXFIX that I used successfully for this.
Jane
Hope This Helps !
I have had this error in the past and think it is likely to be the speed of the Pc that is the issue. IIRC dBase uses the clock speed to assign temporary file names and if th clock ticks over too quickly then these become corrupt.
You need to slow your PC down, I did find a utility called IDXFIX that I used successfully for this.
Jane
Hope This Helps !
I have had this problem on occasion. The only fix I found was to open the table, and copy the structure, go to the new table, append all records, delete the original table, and copy the new table back to the old tables name.
use TblName name
Copy stru with production to temp
use temp
append from table
copy with production to TblName
This keeps all the indexes intact. Reduces the work in fixing it. Hope it helps.
use TblName name
Copy stru with production to temp
use temp
append from table
copy with production to TblName
This keeps all the indexes intact. Reduces the work in fixing it. Hope it helps.
-
1
- #10
NasibKalsi
Programmer
I will go with blorf's suggestion except that not to copy back to the original file yet.
create some indexes and see if it works. Then copy to the same file.
Tryit.
create some indexes and see if it works. Then copy to the same file.
Tryit.
zephyr2004
Programmer
I circumvent the problem in a simple way:
use filcat
copy structure to filcats
use filcats
index on filnavn tag fildex * empty database, no-error
append from filcat *UPDATE MASTERINDEX NO-ERROR
use filcat
copy structure to filcats
use filcats
index on filnavn tag fildex * empty database, no-error
append from filcat *UPDATE MASTERINDEX NO-ERROR
- Status
