Dbase IV - reindex command

[SimonR]

I have inhertied a dbase IV program, on the whole well written with with a couple of bugs, one of which is getting to me !!

The programmer had (sensibly) set up a menu option to reindex the mdx file. But it crashed with "file already open"
I tried running the reindex file from the dot prompt as follows
close all
use <main dbf.
close index
reindex

this either
a) crashes on the first index tag build with &quot;file already open&quot;
or
b) sometimes on the second tag (same message)

I get the same from within the command center

each time it crashes I lose the index it was working on & have to rebuild manually!!

I am getting typers cramp!

how can I get this to work?
any ideas?

Simon

 

[MiggyD]

I only have access to db3+ but this should work fairly well. It's my understanding that 3+ and 4 are pretty close in functionality.

* --- Starts here ---
USE MyData.dbf INDEX indx1, indx2, indx3 (etc...)
* {you section of add/delete/edit code here}
[red]PACK[/red]
* --- Ends here ---

In db3+ if you [red]pack[/red] an opened file that is index it should automatically reindexs ALL index files...This may be the answer you're looking for.

Just remember that packing will erase all records marked for deletion.

Let us know if this helps or not.
--MiggyD &quot;The world shrinks more and more with every new user online.&quot;

 

[SimonR]

MiggyD
mant thanks for the tip, I tried running &quot;pack&quot; - but got the same message again as soon as dbase started to reindex.
I have tried running three separate &quot;index on < > tag <tagname>&quot; commands, with a close index in between each command.
get the same message, sometimes on the first, sometimes on the second command.
I have tried running the index builds in different sequences
I have tried running from the dot prompt, from ASSISt and even from a compiled prg!!
always the same.

could it be bad data?


Simon

 

[MiggyD]

Question, SimonR:

Are the angle bracket actually used throughout the code? or
is there a need for the angle brackets?

from your first example:
[tab]USE <Main.dbf

In db3+ I'd use:
[tab]USE Main.dbf INDEX Client, PhoneNo


Could you post the specific area of code that this problem starts up in? (Please include any relavent lines like: USE, INDEX, SET INDEX TO, SET ORDER , Etc.)

Personally, I would hate to say that it is corrupt data until all other avenues have been checked off--especially if your DBF is more than 150 records. If your DBF is small enough it may not take you too long to scour through EACH record's field to find just one error.

On the lighter side: I'm glad that the PACK command WILL automatically reindex in db4.

--MiggyD &quot;The world shrinks more and more with every new user online.&quot;

 

[SimonR]

This is the exact code, I am trying to creat a multiple index file (mdx) on the database club_mem.
the multiple
close index
staements are my desperate additions!

PROCEDURE ACT05
*-- Begin UTIL: POPUP Menu Actions.
*-- (before item, action, and after item)
*
PRIVATE lc_new, lc_dbf
lc_new=' '
lc_dbf=' '
DO CASE
CASE BAR() = 1
SET EXCLUSIVE ON
lc_message=&quot;0&quot;
ON ERROR lc_message=LTRIM(STR(ERROR()))+&quot; &quot;+MESSAGE()
USE CLUB_MEM
SET ORDER TO M_NUMBER
ON ERROR
gn_error=VAL(lc_message)
IF gn_error > 0
DO Pause WITH ;
&quot;Error opening CLUB_MEM.DBF&quot;
gn_error=0
lc_file=&quot;SET&quot;+gc_prognum
DO &lc_file.
RETURN
ENDIF
lc_new='Y'
RELEASE lc_message
SET EXCLUSIVE OFF
IF .NOT. gl_batch
DO BefAct
ENDIF
SET MESSAGE TO &quot;Re-index main database&quot;
lc_say='Reindexing Database...'
DO info_box WITH lc_say
SET TALK ON

* CREATE TAG M_NUMBER
close all
use club_mem
CLOSE INDEX
CLOSE INDEX
CLOSE INDEX
index on right(trim(upper(duty_type)),2)+weighting+dtos(next_date)+str(memno) tag typedate


* CREATE TAG TYPENO
close all
use club_mem
CLOSE INDEX
CLOSE INDEX
CLOSE INDEX
CLOSE INDEX
INDEX ON LEFT(DUTY_TYPE,2)+STR(MEMNO) TAG TYPENO

* CREATE TAG TYPEDATE
close all
use club_mem
CLOSE INDEX
CLOSE INDEX
CLOSE INDEX
CLOSE INDEX
CLOSE INDEX
INDEX ON memno tag m_number

* REINDEX
SET TALK OFF

IF .NOT. gl_batch
DO AftAct
ENDIF

 

[MiggyD]

Please note that the following code is based on DB3+ functions. I have indicated where the copying should start and finish. I've made some notes after each section PLEASE READ THEM!! I've also left your original lines intact, just look for them and unrem them, if my changes don't work.

IF my modifications DO work, you can delete the debugging section(s) for code compaction.

--Start copying here--

* i don't know if DB4 now stores indices under the MDX extension (as you posted earlier) or if it is a typo. In DB3+ they are stored as Ndx. Not that it matters though.
* i don't know if &quot;dtos()&quot; is similar to &quot;dtoc()&quot;.
* i don't know if &quot;TAG&quot; is similar to &quot;TO&quot;.
* i don't understand why the middle tag refers to it's self and the other two
* refer to each other -- maybe an infinite loop?
* Anyway, here's what I think may work (again based on DB3+ coding only!)....


* CREATE TAG M_NUMBER
CLOSE ALL
USE Club_mem.dbf
INDEX ON duty_type + weighting + DTOC(next_date) + STR(memno) TO M_Number

* Debugging section
CLEAR
? &quot;This is the current status...&quot;
DISP STAT
* End Debugging section

* This is your original line....
* index on RIGHT(trim(upper(duty_type)),2)+weighting+dtos(next_date)+str(memno) tag typedate
*
*MY NOTES:
* 1) You can ONLY INDEX ON FIELD NAMES!! In other words, you CANNOT index on only a portion of a field's name [ex: INDEX ON [red]RIGHT(trim(upper(duty_type)),2)[/red] ]. Unless this is a special feature of DB4.
*
* 2) Not certain if [red]dtos(next_date)[/red] is valid in DB4, but in DB3+ you need to use the DTOC(next_date) to convert to string format.
*
* 3) Not certain if TAG should point to another TAG that points back to this one. Also, I'm not certain of what a TAG is used for in DB4.
*
* 4) Unknown if the WEIGHTING field is a character or numeric field.



* CREATE TAG TYPENO
CLOSE ALL
USE Club_mem.dbf
INDEX ON DUTY_TYPE + STR(MEMNO) TO TypeEnd

* Debugging section
CLEAR
? &quot;This is the current status...&quot;
DISP STAT
* End Debugging section

* This is your original line....
* INDEX ON LEFT(DUTY_TYPE,2)+STR(MEMNO) TAG TYPENO
*
*MY NOTES:
* 1) You can ONLY INDEX ON FIELD NAMES!! In other words, you CANNOT index on only a portion of a field's name [ex: INDEX ON [red]LEFT(duty_type, 2)[/red] ]. Unless this is a special feature of DB4.
*



* CREATE TAG TYPEDATE
CLOSE ALL
USE Club_mem.dbf
INDEX ON memno TO TypeDate

* Debugging section
CLEAR
? &quot;This is the current status...&quot;
DISP STAT
* End Debugging section
*
* This is your original line....
* INDEX ON memno tag m_number
*
*MY NOTES:
* 1) Not certain if TAG should point to another TAG that points back to this one. Also, I'm not certain of what a TAG is used for in DB4.

* Debugging Section ---- Validate indices
CLOSE ALL
USE Club_Mem.DBF INDEX M_Number, TypeNo, TypeDate
CLEAR
? &quot;This is the current status...It should display DBF name, &quot;
?? &quot;all opened indices, and which one is the MASTER KEY index &quot;
?? &quot;which should be the first one opened: M_Number.&quot;
?
?
DISP STATUS
* End Debugging Section


REINDEX

IF .NOT. gl_batch
DO AftAct
ENDIF

--End Copying Here--



Hopefully this will work. Otherwise, I'm going to have to suggest validating the data is in the correct format like making sure that &quot;01/01/1990&quot; doesn't have &quot;01/19/90bo&quot; or that there are no blank fields. Ya, my suggestion will eventually be: &quot;check your data files for corruption&quot; and &quot;run a virus scan too.&quot; but only if this doesn't work, due to the fact that I'm using another platform.

Good Luck!
--MiggyD. &quot;The world shrinks more and more with every new user online.&quot;

 

[LongTimeLurker]

Dear Simon;
I remember having this same problem about 2 years ago. Forgive my bad memory, but I beleive the problem lies in your dBase software version. With the faster machines that have come out since dBase was written, there was a timing problem caused by the reindex command because it could not close a file &quot;fast&quot; enough.
The fix is to find a later version of dBase. I beleive that it is 1.7 or higher?? do a search on the error message and you should come up with the version number needed.
And I have no idea where you can buy a later version if that is the solution.

there is a good explaination of this problem with good solutions at

http://www.apptools.com/dbase/faq/qfao.htm

 

[MiggyD]

LongTimeLurker:

That's a good point about the clock. Question: Did you read my suggested fixes? If so, DOES db4 allow an index on only a particial field name? Also, what do you think about my theory on the &quot;tag&quot;s pointing to one another?? is that a possible problem?

Thanks for any input.
--MiggyD &quot;The world shrinks more and more with every new user online.&quot;

 

[SimonR]

I picked up about the clock speed as well, so I am trying to source a copy of Dabase IV ver 2 on CIX!


Miggy - the MDX file is a multiple index file (equivilent to opeing multiple NDX files) the TAG name is the &quot;aliase&quot; given to the single index within the MDX you want to work with.
I will patch you suggested code into the program and let you know.

I had to have a break before I was tempted to rewrite the whole lot in VB, I mean, I do have a life still!!

thanks for you help

update soon!
S))

 

[MiggyD]

SimonR:

Thanks for the clarification on mdx. I'm glad you were able to break from this problem--I'd probably have pulled ALL of my hair out by the second day! LOL But, I like your method better.

As they say: &quot;If you don't know the answer, leave it. Walk away, get some coffee, walk the dog, and do whatever. 'Cause the problem will still be there.&quot; I gotta try to remember that. ;-)

Hope the above helps some. (even if only a little)
--MiggyD &quot;The world shrinks more and more with every new user online.&quot;

 

[MiggyD]

SimonR:

Just curious if you have had any success?

--MiggyD &quot;The world shrinks more and more with every new user online.&quot;

 

[MiggyD]

I guess you wrote the VB app after all.
--MiggyD &quot;The world shrinks more and more with every new user online.&quot;

 

[circes9]

not sure if you figured this out yet or not.
I didn't go through the code in great detail, but my take is the problem has to do with the &quot;set exclusive on&quot;

Generally, don't set files to exclusive mode, or programs will have problems accessing them.
You do need to open a dbf in exclusive mode to create an index for it.
Attempting to USE a dbf already opened EXCLUSIVELY will generate a runtime error.
Hope this bit helps.
Circes9

 

[JaneC]

I too support several very old dbase systems. AS far as I know the problem is to do with the clock speed of the Pc. I use a utilty called IDXFIX which I downloaded from the internet (sorry cannot remember where) - this enables you to adjust the tick delay. Use with caution, if you make it too long (over about 100) your PC gives every appearance of doing nothing !

Good Luck,

 

[Guest_imported]

I too have had the same problem. I have written many programs with dbase IV's programming language and had no problems with them when running them under DOS or Windows 95 on a Pentium 200 MMX machine. When I upgraded to Windows 98 on the 200 MMX, everything worked OK while in DOS mode, but reindexing did not work when operating in a W98 window. I limped along by going to DOS mode to reindex my files.

I bought a new Dell computer with a Pentium 1.0 Ghz processor and Windows ME preinstalled. Now, reindexing does not work and Microsoft has deleted the DOS mode from WME. Nothing I have tried allows me to reindex; I get the &quot;file already open message&quot; that the original query in this thread noted. Maybe my experience will help someone with a solution to this problem. I believe it is somthing in Windows 98/ME/2000 that causes this to occur. It does not happen with W95 or DOS.

 

[MiggyD]

Has anyone considered writing a &quot;delay&quot; type program? maybe it can be called immediately after each reindex statement to allow the system to commit the data before the next reindex.

I'm not sure if it'll work with MDX files, I only have DBase III+ and it allows only seperate indices.

It's just a thought.

--MiggyD It's better to have two heads to solve a problem from different angles than to have tunnel vision to a dead end.

 

[alexjc]

Having used all versions of dBase from II up, I don't think there is a practical solution to your problem other than to move to dBase IV version 2.00 or later - but I recognize the sourcing problem. Switching off all cacheing in the BIOS and the software seems to work, but not always. The problem lies in the dBase software - indexing a single record in a program usually works fine, reindexing a whole file usually doesn't if the processor MHZ exceeds 200.

On the sourcing issue: there are plenty of dBase users with version 2.00 and above - if Borland were to permit the transfer from one user to another, the problem could be overcome. It would make no difference to them, and get some 'legacy' users out of a very deep hole. LOL

 

[Guest_imported]

I have tried the IDXFIX program noted above by JaneC without success. I tried both the idxfix.com and idxfix.bin versions but neither got rid of the problems with indexing. Changintg the tick delay did no good.

 

[MiggyD]

AuburnDon:

Win95 was still using (or at least for the most part) DOS environment. After W95, the GUI environment reigned and DOS became a &quot;Shell&quot;. Like..umm??...Like a word processing app (on a computer) does NOT control the whole system (the environment) it works WITH the environment but does not control it.

In the case you mentioned, (Win 98 & ME) control the environment and DOS is NOW!! like the word processor app in that it works WITH the environment but doesn't have total control of it...Window's GUI controls it.

I don't know if you can understand what I'm saying but I hope some of this somehow is understood. This particular question keeps arrising in other forums I visit. And I try to explain it as best as I can but most others still don't comprehend that DOS is an application and NOT an environment--as it was in the olden days.

Hope this helps some what,
--MiggyD It's better to have two heads to solve a problem from different angles than to have tunnel vision to a dead end.

 

[JaneC]

AuburnDon,

Sorry IDXFIX didn't work for you. I've found it works 99% of the time if I set the tick speed to 100

(IDXFIX /T00100)

Jane