index files

[metron9]

Just starting out here old CLIPPER programmer with tons of code to update to foxpro your answers to others questions has allready helped me get past some questions thanks.

I do have a tip on index files.

I use a function to open files called NETOPEN
I am running Novell 5.1 and CLIPPER/DOS EXEs
It checks for index files and creates them if they are not found. If you get a courupted index file the user can just delete the file and rerun the program to create new index files. Any new programs will have an reindex button.
There is a question though, is there a good way of checking if index files are courupted?


Here is the calling code: up to 4 index files.
Table index name Field name
netopen('PRINTERS','tmpprint' , 'pname')

and the function:

FUNCTION NETOPEN
local tmpscr
PARAMETERS FIL,NTX1,FLD1,NTX2,FLD2,NTX3,FLD3,NTX4,FLD4
TMPSCR=SAVESCREEN(0,0,24,79)
if .not.net_use(FIL,.f.,3)
err('Unable to open '+FIL)
RESTSCREEN(0,0,24,79,TMPSCR)
RETURN(.F.)
endif
DO CASE
CASE PCOUNT()>2
if .not.file(NTX1+'.NTX')
if fil_lock(3)
SHOWINDEX(FLD1,NTX1)
index on &FLD1 to &NTX1
unlock
else
err('Unable to create index file',NTX1)
use
RESTSCREEN(0,0,24,79,TMPSCR)
RETURN(.F.)
endif
endif
CASE PCOUNT()>4
if .not.file(NTX2+'.NTX')
if fil_lock(3)
SHOWINDEX(FLD1,NTX1)
index on &FLD1 to &NTX1
SHOWINDEX(FLD2,NTX2)
index on &FLD2 to &NTX2
unlock
else
err('Unable to create index file',NTX2)
use
RESTSCREEN(0,0,24,79,TMPSCR)
RETURN(.F.)
endif
endif
CASE PCOUNT()>6
if .not.file(NTX3+'.NTX')
if fil_lock(3)
SHOWINDEX(FLD1,NTX1)
index on &FLD1 to &NTX1
SHOWINDEX(FLD2,NTX2)
index on &FLD2 to &NTX2
SHOWINDEX(FLD3,NTX3)
index on &FLD3 to &NTX3
unlock
else
err('Unable to create index file',NTX3)
use
RESTSCREEN(0,0,24,79,TMPSCR)
RETURN(.F.)
endif
endif
CASE PCOUNT()>8
if .not.file(NTX4+'.NTX')
if fil_lock(3)
SHOWINDEX(FLD1,NTX1)
index on &FLD1 to &NTX1
SHOWINDEX(FLD2,NTX2)
index on &FLD2 to &NTX2
SHOWINDEX(FLD3,NTX3)
index on &FLD3 to &NTX3
SHOWINDEX(FLD4,NTX4)
index on &FLD4 to &NTX4
unlock
else
err('Unable to create index file',NTX4)
use
RESTSCREEN(0,0,24,79,TMPSCR)
RETURN(.F.)
endif
endif
ENDCASE
UNLOCK
DO CASE
CASE PCOUNT()>8
set index to &NTX1,&NTX2,&NTX3,&NTX4
CASE PCOUNT()>6
set index to &NTX1,&NTX2,&NTX3
CASE PCOUNT()>4
set index to &NTX1,&NTX2
CASE PCOUNT()>2
set index to &NTX1
OTHERWISE
SET INDEX TO
ENDCASE
RESTSCREEN(0,0,24,79,TMPSCR)
RETURN(.T.)

 

[rgbean]

Code written to verify index integrity would require longer to run than simply recreating the indexes (especially if written in VFP code). And you'd have to "lock down" the table (open it exclusive) anyway so no one could change it while you were checking. If you "think" the indexes may be bad, you could check the header to make sure that that structure was correct, and then just reindex. If the header is bad and you are not using free tables, I hope you're using the Stonefield Database Toolkit, or you have a recent backup.

Rick

 

[MCTCO]

all you have to do is

select workareaalias
set order to someorder
go bottom

if you get an error the index is corrupt

 

[danceman]

its not even practcle to do an error check on it. I find it handy to check to see if the last person exiting the database, if so then run idex routine.

many times the index is not corrupt but out of order. I find that indexs from the before vfp days has improved. Attitude is Everything

 

[DSummZZZ]

...And, issuing GO BOTTOM doesn't always error out if the index is corrupt. There may be funky records in the middle someplace.
Dave S.

 

[wjs2]

DSummzzz,

Hi. I have seen those funky records in the middle. In Fox 2.6. Since moving to Visual Fox 6.0 I have not encountered the problem but it is always sitting back there in my mind making my mind squirm. I never learned the reason for the records being there and this has troubled me some. Do you know if there was some inherent problem in 2.6 that was cleared up? Is this still something to worry about?

Thanks
WJS

 

[wgcs]

And just a note... .DBF files are marked if they have an associated .CDX file, and if the .CDX is missing, and error is thrown. So your method of deleting the indexes and restarting the program will have to account for this error.

 

[DSummZZZ]

wjs2,

I encountered that scenario about a week ago. Using VFP 6.
It hasn't gone away.
Dave S.

 

[rhyd]

i also thought this problem had gone away - but no, I saw it in a large (200MB) VFP table just the other (unhappy) day. The solution is to migrate to sql-server which is what M$ want us to do anyway! it isn't in billyG's interests to make foxpro a rock solid enterprise tool because it would be competing with other MS products... so the problem persists over decades.

 

[DSummZZZ]

So rhyd,
You getting paid by the MS SQL promotion team or what?
Dave S.

 

[jryan224]

Hi all,
We have two major VFP6 apps running at 55 locatons accross the state. (800+ users) Each location has a server which is runing both apps. Thankfully all 55 loctions are accessible on our intranet. I have to repair index files al least once a week. Sometimes a single location repeatedly being corrupted or on occasion I have had up to 5 locations in line waiting for me to find the corrupt table and fix the index. Usually will replace it and reindex. We believe from users just shuting off the PC and sometimes power outages. (Glad I don't have to drive to them. LOL)

I have seen corrupted records (open retangles in the fields) in the beginning, end, and middle of the files.

We are currently moving to one MS SQL database for the state. Currently another developer in the shop is re-writing one app in VB.net for the SQL backend and when this is in place, I will be re-writing the other also into VB.net utilizing the same SQL database.

Jdemmer

 

[rgbean]

I've found that most index problems on file servers can be avoided with just a little hardware, proper configuration and educated users.

First, all servers and workstations should be on UPSs to prevent power outage problems. Next, if you are using a Novell file server, it's critical to make sure all the workstations are using current Netware drivers that have had some of the default settings changed - the caching ones in particular, but check the Novell support site for the specifics - they keep changing the properties. If you are using NT / 2000 for a file server, then these need some caching properties reset after each reboot (unfortunately they aren't persistant!).

Users should all be taught to properly close out your applications and NEVER just power off the machine. With some minamal logging in your app, it isn't hard to identify those that are violating this simple requirement.

Rick