1. replacing it with a healthy backup file
2. Doing REINDEX
(Anyone questioning the validity of the method may simply copy a CDX at any stage, then change some data (so the CDX changes), finally replace the current with the copied (outdated) CDX and reindex.)
If the CDX index info is okay, you can even fix the CDX with REINDEX alone.
So do you have VFP at hand or only your software?
If so, you might get
which mainly gives you a VFP command window.
Do a copy of your data folder and then just type in [tt]REINDEX[/tt] and you'll be prompted for which DBF to reindex. Pick a DBF from your folder copy and see if that fixes it.
Well, if a table is broken, why does anyone have it open?
As I suggested making a copy first, that's even more unlikely to happen, when you pick a copy.
So the main reason would be opening the DBF for shared access - even if you're the only one, it's still opened for shared access.
There is a checkbox in the open file dialog, enabling you to specify you want to try exclusive access. At least once you see the error message, you know you have to check this.
I forgot to mention this, as exclusive access is a default in the VFP IDE, but as you see you get the right hint on what to do anyway.
Most likely vRunFox is configured for shared access by default.
Bye, Olaf.
PS: Yes, I'm still sorry for you, even if you could have seen this yourself. I assume not coming back you either succeeded or have found other help elsewhere, working straight out of the box.
PPS: And you can do [tt]SET EXCLUSIVE ON[/tt] so this is checked by default. Also, if that works you can easily loop a whole directory with ADIR.
Thanks Olaf. I should have mentioned at the beginning that I am not a programmer but just a novice end user who wouldn't have figured this out without your going the extra mile. Might you be interested in doing data conversions for us in the future? Our program is Best Consignment Shop Software if you care to download the demo and take a look at the database. Thanks again!
The PS in my response just reflects the experience I made with people posting to multiple forums and only continuing in the ones, which have simply hit the nail better. It's a bit unfortunate, but I am also not offended by that, it's a natural thing to get your problem seen by as many experts as possible.
And about the explanation of what you could have seen: I agree you would need to be a sentient to remember there was that "Open exclusive" checkbox. Perhaps it's more the stance of a developer retry something, which failed (in the light of new knowledge it sometimes helps, it can also become a tendency of banging your head against a wall). Therefore my explanation. I also wanted to point out, that the VFP messages are typically pointing out the problem. They can also be misleading at times, but I had worse experiences for example with PHP's error reporting. Even Visual Studio is often puzzling. But I'll stop the developer talk here.
I assume you could now fix a CDX or two, do you still have a current problem? I hinted vRunFox also could run a program to go through all DBFs of a directory, I can help you with that, if you need to, because it's not obvious how you create a PRG code file with vRunFox. The menu is mainly disabled, including File->New and even if menu items were available, I now know you won't be able to program the necessary code even having a hint on using ADIR.
By the way, thanks for that offer, I'll take a look and contact you.
OK, do a copy of the data dir to C:\databackup\ - That's mainly to be able to revert and restart repairing.
Then do another copy and call it C:\datarepair. Within the vRunFox command window change to that directory via
[tt]CD C:\datarepair[/tt]
Now enter [tt]MODIFY COMMAND[/tt] and an editor for "Program1" will appear.
Copy over this code:
Code:
For i=1 To ADir(laDBFs,"*.dbf")
Use laDBFs[i,1] Exclusive
Reindex
Endfor
Then Save that as reindexdir.prg into the C:\datarepair directory (The file menu will have the "Save As" menu item active when the editor is active).
Type in [tt]COMPILE reindexdir.prg[/tt] and if you look with Windows File Explorer, you'll see an FXP file will be created.
You can execute that now with [tt]DO reindexdir.fxp[/tt]
You'll see all CDX files will get new file dates, it can take a while, depending on DBF sizes.
It'll fail on CDXes, which are so corrupt, even their header has no good index information for the REINDEX command to be able to reconstruct them. If that's the case, older CDX files might help, as I initially explained. I hope this software has a backup feature or at least your company does backups, so you'd have older but intact CDX files, which now could be worth gold. The empty files from a new installation could also help.
I'm quite confident it'll help, but can't tell, what legacy formats of CDX files this might be. The repair could turn out worse than your original situation. Therefore I suggest leaving C:\databackup\ untouched. For the same reason and on top of that because some user might be in the system you better not repair the live data, too. It typically pays and saves a lot of network traffic to work on locally copied data. Of course, you have one roundtrip, but any working on the DBF and related files now done on local files is no payload on the network.
To test the repair you of course now will need to copy that back to the data directory of the shop system. You'll notice if someone is in the system, when some file has a current DateTime now, later than the files in C:\databackup\. Of course, that will mean copying back the repaired data is a step back in the data. So of course ideally you do all of this off hours.
Oh, and you see, that's a very short snippet. I don't charge for this.
I have downloaded the "Intro" version but didn't have the time to look at it so far. I'll install to look at the database it creates. I'll also see if it comes with source code, but I doubt that. Knowing the database will be helpful with any tasks about conversion. I assume you want to move your data to another shop system? Do you have regular index corruption? It might be due to an SMB file protocol feature called opportunistic locks. VFP doesn't cope well with them.
I'll get back to this on Monday. I'm in Germany, and to us, it's already far into the evening. Have a nice weekend!
I have had rare instances where the CDX had, for whatever reason, turned into a zero-byte file. Presumably something crashed early in the update or reindex process. Of course, REINDEX won't work in such a scenario. That's where having prior backups is invaluable. Or having code or special tables holding the information on the index tags, expressions and other data.
In this case, healthy CDXes can be retrieved from a setup of that software somewhere it's not yet installed. But regular backups are a must have for obvious reasons anyway.
I did a test installation of BCSS and cannot use the software, as it tries to use a csftpax8 OCX, but installs a previous version csftpax6 only.
Also, the software doesn't come with source code as I expected, but I can see the database coming with it, which is sufficient basis for doing a data migration project.
I take it you are not the vendor but a customer using that shop software, so only knowing the site I'm unable to contact you. If you're still interested in a developer able to cope with data conversions, just contact me via LinkedIn, you'll find me there.
Thanks Olaf. I'm not the programmer - just the person who put up the money to develop Best Consignment Shop Software. I own the source code but it is in the programmer's possession. You can reach me at sales at bestconsignmentshopsoftware.com. Feel free to look up WhoIS... My name is S-t-e-v-e H-e-n-n-i-n-g
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.