Link to home
Start Free TrialLog in
Avatar of timwatts041300
timwatts041300

asked on

CDX Editor for FoxPro database??

Hi,

I'm still trying to fix a FoxPro 2.5 DOS database. I'm having problems after I zap client and employee dbf files. The program seems to hang up, rather then let me start fresh and input new data. Do I need to edit the companion CDX files as well?

Just for the sake of asking, what is a good shareware editor that will handle CDX files?? I would like to see what is in these files.

I appreciate the help!  :o)

Tim

Avatar of dcl
dcl
Flag of Australia image

As long as the CDX files where in use when the dbf was zapped (see "Use" command), they should have been cleared as well.  You shouldn't need to edit them at all, as they are only used by FoxPro for index based operations.  If you ever have a problem, you can always deleted them & rebuild them (see "delete tag" & "index" commands)

What do you mean you are trying to "
fix" a Fox 2.5 database?
Avatar of AliFox
AliFox

You could try seperating the CDX from the DBF by renaming the DBF something els. Then copy the original CDX to the renamed DBF above and try reindexing.

It may simply be be link which needs to
be restored.
Avatar of timwatts041300

ASKER

I am not using Visual FoxPro when I zap these files. I am using a shareware zap utility.

This is a DOS standalone database created with FoxPro 2.5. It runs in a DOS window under W95.

(I am not sure regarding how to make sure the CDX files are in use when they are zapped.) ???

If I zap the dbf files and then use the Reindex command built in to the program, what will that do?

Thanks.

The DBF, CDX (and FPT if exist) files are handled as a unit. A (regular) zap command modifies all files; also the CDX file. If one of these files are in use, normally the zap routine can't start work, because it needs exclusive access to all files.
The REINDEX command creates new index entrys depending on the database contents. It's very helpful to repair an inconsitent CDX file; You should follow AliFox' advice.
I would suggest that the utility you are using is NOT updating the related files (CDX & FPT) as suggested by (mb)

However if you have FOXPRO 2.5 you could use this to zap the file.

I assume from the use of a third party utility you don't have foxpro at all ?

A cheap and nasty solution to the problem is to keep a empty copy of the tables, cdxs & fpts and use these to overwrite the files effectively zapping them.

Is it a foxpro program (EXE) that is manipulation the tables?. If so then you must have the foxpro runtime libraries installed, in which case a simple foxpro application (another exe) could be employed to zap the required files
AliFox,

Your answer seemed a little incomplete. The directions were somewhat incomplete to me.

"You could try seperating the CDX from the DBF by renaming the DBF something els. Then copy the original CDX to the renamed DBF above and try reindexing.

It may simply be be link which needs to
be restored."

How does that separate the file by simplying renaming it? How would I copy the original CDX file to the renamed dbf?? Wouldn't it be in the same place that it was since all that is described above is renaming the dbf? The cdx file in the above scenario has not moved, the dbf was just renamed. How do you copy the cdx file to the newly renamed dbf?

Please do not misunderstand, I am an outright NOVICE at this so you need to clarify your answer a little. It sounds interesting. Basically, after I have zapped, can I just hit the reindex??

Remember, I do not have FoxPro. Just a shareware zap utility. I have been asked to make an old FP 2.5 (DOS) database blank again so it can be used as a brand new dbase with no client entries. I do not know if the shareware knows how to zap or keep track of all the files, as in the cdx. I know if there is a companion FPT file of the same name, it does that also along with the dbf. I have never seen anything mentioned about the cdx when I zap. Am I supposed to?

I was merely zaping the dbf files that had existing client data, then trying to run the program to re-input new client data. It would hang up and say "Error # 5. Record is out of range. Try again later."

Since I do not have VFP 6.0, do you suppose the REINDEX command that was built into this DOS database is all I need to hit after I zap the dbfs??

Does this explanation help more? I hope I am being explicit enough. I certainly appreciate the help VERY much. Thanks for your effort.  :o)

Please clarify your previous answer with a little more detail if possible.

Thanks again AliFox!  :o)

Tim

"Record out of range" typically indicates an index problem.

If the files are completely trashed, using Reindex might not work.  Reindex rewrites the index files. If there is a problem with the index files, it would only rewrite the problem also.

The prefered method to rebuild indexes is to delete the indexes and rebuild them from scratch, so it depends on how the DOS program does the reindex.

But without having Foxpro, I would try your shareware zap utility, then the DOS program's Reindex, then import the data.

PF
The previous comments are very good.  If there is a reindex command in the FoxPro application, then use it.

Here is another alternative.  If you have MS Word / Excel / Access (or any other ODBC compliant app), open the Foxpro dbs via ODBC, then delete all the records.  ODBC should update the indexes as well for you.
An update:

Thanks to all who have offered advice on this one. I should probably resubmit this one with the title of "Zapping FoxPro 2.5 Databases."

Here's where I stand so far. I have tried the Reindex function in the database program and once again I get an error that says, "File 'dbempl01' does not exist. Try again later."

I am not on the machine where the actual database resides. I supposedly have a complete and full copy on my machine here at home that I was given to work on and fix for my wife's uncle. I will go to his office tomorrow and see what gives with the "dbempl01" file.

I would like to test the Reindex function while I'm there, but would like to know first if there would be an adverse effect if I do that with their database. I am assuming if there is no change in the db that Reindexing will have no adverse effect. Please advise if this is NOT a good idea to test the Reindex function.

I have completed the major portion of this project without having to break down and buy VFP 6.0. (Actually I tried to, but no one carried it in any of the major software stores here in the Minneapolis area.) If I need to break down and buy this just to finish 1/10th of the project, I guess that's obviously what I will do. If I can avoid it, I would prefer not to buy VFP 6.0 as I already have Access 2000 and I do any of the limited RDBMS work I have to with that. I do more tech oriented stuff so the RDBMS is out of my expertise. I sincerely appreciate all the help that has been offered.

Any more thoughts now on the Reindex function? I would like to test it on the actual machine the database is on tomorrow, if there is no adverse effect.

Thanks again all!  :o)

Tim

You can do everything you want with the database (also REINDEX), but at first your should make a copy of all related files!

If you have Access, you can create new FoxPro tables:
- Create a new access database
- Import the FoxPro table to the tables area
- Export these imported table to another location as external database using the "FoxFro 2.5 (*.dbf)" format.

Access creates a new (I hope consistent) database structure, so you should get a working FoxPro database.
Tim,

I agree with all that pforman has said.
If the reindex doesn't work then you will need to rebuild the indexes from
scratch.

if you are unable to rebuild the indexes from scratch then try and seperate the CDX from the DBF as follows:-

Find a copy (last night's backup) of an old CDX file which is attached to the
database which you are having problems with. Then delete the original CDX file
from the corrupt database. Then, taking your old copy of the CDX file rename it
to the name of the corrupt database.

Finally, as the indexes will be out of
sync by 1 day (approx), reindex to update the CDX file.

Alternatively, make copy of the original
DBF and CDX file. Then write a little
program to copy all contents of first DBF to second DBF. Reindex 2nd DBF. Delete original DBF and CDX and rename
2nd DBF and CDX back to the original names.

Hope this helps.
Tim,

You can do anything you want, so long as you backup first.  Then have fun.  

Obviously, you don't have a complete copy at home, due to the file not found.  Is there a dbempl01.dbf file present.  If so, it might be in the wrong directory.

If you do need to rebuild, Accesss will not help.  As it will not create the CDX (index) files for you.

As far as buying VFP, the stores probably only carry it as part of Visual Studio.  If you do need to buy VFP, I'd go mailorder.

PF
To pforman:
Access can help. If you use Access to export a table into a FoxPro format, it also creates a CDX file.
When you finally get a zapped out version of your data files, copy them to a new folder and save them.  The next time you need to do this, copy them to the folder holding your data.  

Good Luck,
Mike
Update...

It seems I may be in one of those "Can't get there from here on this one." I have been able to do 9/10ths of this project using shareware products from the net. Now the one simple thing such as zapping and then reindexing has caused me to reconsider purchasing VFP 6.0 to end this nightmare. Apparently the Reindex feature in this databse isn't working for some reason on my copy, nor on the original located on the server. I am stuck.

Pforman: I wish I could try the export suggestion but I am unable to import the files into Access in the first place. Here's what I get when I ty to open the file or convert to Access 2000... (all rookie stuff I'm sure)

1) IMPORTING THE FILE FOXUSER.DBF WITH ACCESS:

I go to FILE... GET EXTERNAL DATA... and then IMPORT... I get an error message that says, "Access was not able to perform this operation because the project is not connected to a SQL server database."

2) DOUBLE-CLICKING ON THE FILE FOXUSER.DBF:

"Unrecognized database format"

3) OPENING THE FOXUSER.DBF FILE IN ACCESS 2000:

I go to FILE... OPEN... then select the file FOXUSER.DBF. I get two diferent errors that say...

"Cannot locate the requested xbase memo file"

"Microsoft Access can't open the table in Datasheet view"

The MS Knowledge Base says, "You tried to access a dBASE (.dbf) file, but the file's associated memo (.dbt) file could not be found. Make sure the .dbt files is in the same directory as the .dbf file, and then try the operation again."

DCL: I was not able to figure out how to open the dbf with the ODBC. How do I get it to open a dbf file with the ODBC?

Migrating this data to Access has been way tougher than I thought it would. I'm seriously thinking about breaking down and just buying VFP 6.0. That way I can finally do the zapping and reindexing there and finish fixing the old FoxPro 2.5 DOS database.

I have also decided to try my hand at writing a new database with Access2000, just to see if I can do one better than the DOS one I'm trying to fix. (Going to try at least.) I did it once with Access 1.0 so I figure 2000 has to be easier. (Yeah, right.) I'm sure you'll see me posting in the Access section. :o)

PS... do I keep this question up until I find the right fix? Sorry, I'm obviously new to EE and don't know what to do when I don't get the right fix. Thanks for any advice.

Tim
Is it only the file named "FOXUSER.DBF" you want to fix? These DBF has a special meaning for FoxPro - FoxPro or FoxPro applications stores some preferences in it. There must be a DBF, CDX and FPT file (It seems, that your FPT file is destroyed). Normally you can remove all files "FOXUSER.*". The application creates new versions, if these files doesn't exist.
More on last update...

As far as the ODBC goes... (I forgot to post the error I was getting, sorry)... it says:

"ODBC--call failed. General error: Invalid file dsn 'C:\Documents\Access\Newdb\data\employee.dbf' (#556)

That is what happens when i try the directions above for ODBC.

MB: I want to zap all the files with client data, not the Foxuser.dbf file. I can zap the dbf and fpt files just fine, but can't reindex the cdx files. Apparently the Reindex function has been disabled somehow in this db.

It looks as though that is my only hold up so I will break down and buy VFP 6.0 just to fix this last end of the problem and then be done with it. Can't believe I got this far without it and now am forced to buy VFP for such a small issue. Oh well.

Thanks again!

Tim

ASKER CERTIFIED SOLUTION
Avatar of dcl
dcl
Flag of Australia image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
To DCL...

Thanks. I never did anything with the ODBC in Control Panel before so maybe you have something there. I will try your suggestion and see what happens. I'll let you know.

My email is timwatts@mm.com

Thanks again DCL!  :o)

Tim


ONE MORE UPDATE... Well, after all the numerous difficulties trying to zap and reindex this old 2.5 database, I finally broke down and bought VFP 6.0. (Not a bad price either for the pro edition, $338.)At any rate, I have successfully been able to zap and reindex, and have succeeded in blanking the database. I have a couple minor problems (such as defaulting the printer on a network) that I will address later, but for now I would like to say thank you to all who gave me input. Because of the way it went, I'm really not sure who best to give the points to but DCL was one of those who mentioned doing it with FoxPro early on, plus he also sent me a standalone app to do it as well, so I will give him the points with my sincerest thanks. I would love to say that I'm done now but it seems they just keep thinking up new things for me... like, "Why can't we get the printer to print to another printer on the network?" I suppose that'a a networking forum so for now I will say a heartfelt thanks to all.

Best regards!  :o)

Tim Watts

Comment accepted as answer
He was one of a few who provided the  obvious answer but also sent a standalone app to also do the same thing I needed. Great effort DCL!  :o)