FoxPro 2.6 index problem 1

[papagregoire]

I've run a core database for years, with both direct access (on the aged iMac OS 8.5 required to run the system) and as a server, data accessed by mySQL Client apps on other computers (works only in Classic). Troublesome sometimes (my son wrote the db in his early teens), but never before anything like this.

1. Yesterday morning FoxPro (and the iMac) locked up while writing a web order download from one of the Clients
2. CPU restart OK, but neither the local Accounts nor the db server would load. Accounts gave messages "Not a table.dbf" and "Alias XXX not found"
3. I unwittingly made matters worse by opening some of those tables in VFP and using Reindex command (for reasons I don't understand the db has to run on 2.6, but many maintenance functions are more easily tended in VFP -- but not this one. Even worse perhaps was an attempt to run Gentags. Result was that I had VFP indexes, unusable by 2.6
4. I opened/ tried to open every dbf (a LOT of them) in 2.6, thereby identifying the files (about 25 of them) with bad indexes
5. I used Export to create (in a separate folder) new dbf & fpt for all those files -- but cdx's were not created. All of those files open fine in 2.6
6. A Microsoft tech note (ftp://ftp.microsoft.com/misc1/DEVELOPR/FOX/KB/Q202/5/20.TXT) says (apparently erroneously) that index problems are easy to fix in 2.6, simply by deleting the faulty index(es) and allowing the program to re-create them. Actually, it says to "re-create" the cdx files, but gives no clue as to how to go about this.
7. Resources available, in addition to the newly-created Export files: The entire database folder (cdx's and all) from yesterday morning, messy as it is (most of the files seem OK; open OK in 2.6); a complete backup of the database files from 7/19/12 (don't I wish I'd backed it up Thurs. night!)

Elsewhere on this forum there's reference to a command-line reindex command (I'll go back and find it), but I'm assuming this is likely to do nothing if there's no cdx file there to begin with (nevertheless I'll try it on an isolated copy of one dbf/fpt pair).

Until this problem is resolved, all inventory & shipping functions here are somewhere between badly crippled and dead in the water. Any assistance DEEPLY appreciated. Making matters worse, I have to leave here (for the week) tomorrow (Sunday 7/29/12) afternoon. I hope I can leave knowing the problem has been resolved!

 

[mmerlinn]

I run FP2.6 on Mac OS 9.2. Occasionally the Mac freezes and I need to reboot. If that happens when accessing the DBF files, the indexes are always corrupted.

What I do is

1) delete the corrupted CDX(s),
2) copy some old known-to-be-good CDX(s) for the same DBF(s),
3) move the copied CDX(s) to the folder(s) that had the corrupted CDX(s),
4) rename the copied CDX(s) to the correct name(s),
5) then reindex the DBF(s) one at a time from the main FP menu.

Unless I have modified the indexes since the time of the known-to-be-good CDX(s), all of the indexes are restored exactly as they should be. If I have made modifications, I have to redo all of the modifications again.

Every time this happens I swear I will write a automated routine to recover from the corruptions, but so far in 15 years I have never gotten around to it.

I fully back up twice each week, and have 15 years worth of valid CDX(s) available, so, even though irritating, it does not take me long to recover when I have corrupted indexes.

mmerlinn

http://mmerlinn.com

Poor people do not hire employees. If you soak the rich, who are you going to work for?

"We've found by experience that people who are careless and sloppy writers are usually also careless and sloppy at thinking and coding. Answering questions for careless and sloppy thinkers is not rewarding." - Eric Raymond

 

[papagregoire]

Thanks so much for this input. I have more data (and did finally succeed in getting the direct front-end on the iMac up & running, but not the database server), but must leave within a couple of hours for a weeklong trip; more next weekend.

 

[Dan Freeman]

The phrase "database server" has a very specific meaning in a Foxpro applicaiton and it has little to do with Foxpro. It generally refers to a back-end server running MS-SQL Server, Oracle, MySql, etc.

If that is what you meant, you'll need to provide more information about which server product (version, platform) you're using and exactly what is going on, and probably ask in a support forum for that product. But since you appear to be describing Foxpro errors, I suspect you've decided to redefine the phrase "database server" to mean something else.

It's probably blindingly obvious TO YOU what you mean, but that's because you already know what you mean. We don't.

 

[papagregoire]

OK, back at it, Dan, and just as frustrated as ever. I discovered to my horror that apparently in the stuff/unstuff process (Stuffit Pro) all the index orders got set to 0, so nothing will open at all using CDX's from the Stuffit files. Sorry about the nomenclature problems (I really am a duffer in this area!). I have a common set of database files ("Database Data") which are accessed in two different ways: (1) by what I call a "front-end" program on the iMac ("Accounts") which runs on FoxPro 2.6a; this is now running more or less satisfactorily; and (2) a "server" program ("main.prg", runs on Visual FoxPro) which serves as host for access by a MySQL client program ("Client"), which runs (or rather is supposed to run) on Classic on other computers. This is not currently possible as main.prg refuses to launch, claiming "no index order set" on multiple files. The two accesses handle different areas (sometimes common) of the database set.

That's the background. I'll be MORE than happy to pay for assistance in resolving this problem -- to the end of getting out of FoxPro altogether in the proximate future!

What I have to work with: I have made no intentional changes to any indexes ever. I have (I hope!) intact complete database (including index) files (not passed through Stuffit) from as late as April 2009 (no program changes of any kind have been made since long before that date). I have almost completed updating the recent backup files (via "Accounts") to bring them current (still a few web orders & shipping log entries to complete).

Any assistance in accomplishing the migration will be greatly appreciated (and compensated). Most of the database needs to be migrated to MoneyWorks Gold, which is equipped to handle its accounting, customer database and inventory functions. The most resistant area yet encountered: Actual inventory control: creating & printing barcoded package labels; scanning in storage locations for the packages& boxes thus created; deletion of "used" packages. This may have to be done via a stand-alone of some kind, as MWG doesn't (it seems) have a ready "socket" for the function.

I trust I haven't been guilty of sloppy writing! And I really DO need help! Happy to move this to private communication if you wish.

 

[JRB-Bldr]

Be cautious of what you ask for on this forum.
Just in case you missed or over-looked them, there are posting rules (see them just below the POST button).

Promoting, selling, recruiting and student posting are not allowed on Tek-Tips Forums.

We are here to assist/advise you in your own learning opportunity where FoxPro (old versions 1 to 2.6) is involved.

Good Luck,
JRB-Bldr

 

[Dan Freeman]

I trust I haven't been guilty of sloppy writing!

Yeah, you kinda have. You refer to a VFP "server" and a MySQL "client".

VFP is not a server product.
MySQL is not a client product.

You mention indexes "getting set to 0". That just isn't a thing in VFP or FPM. Nobody has any frame of reference to help you because nothing like that exists.

You also mention Stuffit Pro. Any problem with their compression product should be asked of the makers of Stuffit Pro. It isn't Foxpro's problem if the data starts out good and isn't good after being passed through Stuffit.

Everyone would love to help you out but when you make up your own definitions for words that have strongly entrenched meanings you complicate the task.

(Also note that Foxpro on a Mac is so old I'm surprised it even runs at all!)

 

[mmerlinn]

(Also note that Foxpro on a Mac is so old I'm surprised it even runs at all!)

The same could be said for any FoxPro program on any machine, DOS, Windows, Unix, and Mac, yet this whole forum is geared to keeping all of these legacy versions working.

Considering that, as far as I know, there is NO Mac program out there that even comes close to the capabilities of Mac FoxPro, us Mac people are kind of stuck with FP on old machines.

mmerlinn

http://mmerlinn.com

Poor people do not hire employees. If you soak the rich, who are you going to work for?

"We've found by experience that people who are careless and sloppy writers are usually also careless and sloppy at thinking and coding. Answering questions for careless and sloppy thinkers is not rewarding." - Eric Raymond

 

[papagregoire]

Please forgive my ignorance! I'm an old man wandering in a land of high-techies. To recap (the specific problem):

FoxPro (on an aged iMac, OS 8.5) is supposed to run a program (main.prg) which provides and received data from mySQL client applications (multiple installations)on other computers running either 9.2.2, or Classic within OS 10.4.11. Some of the data (as compiled) is only accessible by this route. [E.g., while I can access the individual line entries for a checkbook from VFP on the iMac, I can only get balances, etc. from the Client installations.] When I attempt to launch main.prg (by dragging it onto the VFP icon, as it's always worked), I get the results shown in the attached screenshot.

My resources: (a)a presumably intact set of backup files from a few days before the crash (from which I'm running the direct-access program, "Accounts", on the iMac, and to which I've restored the missing 7 days worth of data); (b) a set of .cdx files from a not-compressed/ decompressed and presumably intact backup from 2009.

If I can succeed in getting the data-server program to launch properly, I can probably get the data I need extracted and moved onto an at least relatively modern platform (I did succeed in doing this with the table which contained inventory package locations).

Any help greatly appreciated. I don't think I'm guilty of sloppy writing — just ignorance of techie-speak!

 

[papagregoire]

OK, I'm a dummy. Forgot to attach the screenshot. Here it is.

 

[papagregoire]

OK, that didn't work as I expected. I'll try again. Triee mediafire without success. Foiled again. I have a screenshot of what happens on the iMac, but can't find any way to get it into this message. Any help?

 

[DSummZZZ]

All you can do is point a link to the picture hosted on a web server somewhere.
You can't post a picture in the forum.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[papagregoire]

Out of it for another week (I'll be away from the troublemaker FoxPro installation), though certainly happy to see any insights. What that screen shot (which I can't find a workable method to post) tells me ia: "Table has no index order set", with a line of code which reads "USE 'inv pmts' IN 0 ORDER pmt_no". Following lines of code have the same structure with different table names. If I tell the dialog "Ignore" it just bounces me to the next line of code with different table name. Oddly (to me, admittedly NOT a programmer!) there are a few preceding lines of code with the same structure ("... IN 0 ORDER....") which apparently did not generate such an error message.

Is it reasonable to hope that if I replace ALL the .cdx files in the "working" database folder (rather, a copy thereof) with intact .cdx backups from 2009 (no structural changes have been made in the interim; only actual data) I might be able to run the program? (This would be more than just a bit tedious, as there are several hundred files involved, but well worth the effort if it makes it possible to run the program, even if only for a short time.)

 

[Olaf Doschke]

Indeed if "USE ... ORDER pmt_n" causes an error "Table has no index order set", this points to the pmt_n index tag missing or being defect.

You can repair an index by an older cdx, yes, but that's just half the solution, you then have the index expression in the cdx header intact, but the index is out of synch. You'll need to REINDEX the tables to repair the indexes fully. This will rebuild the cdx using the index tag names and expressions and types stored in the header.

Bye, Olaf.

 

[mmerlinn]

It appears to me that you need to replace the offending CDX with a known good copy, then REINDEX as I noted in my first post.

If you just replaced the CDX without doing everything in that list, your program will still not work.

According to the error message you are getting, it appears that you either did not replace the CDX, or you did not REINDEX it.

The reason you are only getting one error instead of a slough of errors is that only ONE CDX is bad. So, that is the only CDX you need to worry about. Just determine which DBF you are accessing at the point of error, then tackle only the corresponding CDX. No need to replace any CDX that is not bad.

mmerlinn

http://mmerlinn.com

Poor people do not hire employees. If you soak the rich, who are you going to work for?

"We've found by experience that people who are careless and sloppy writers are usually also careless and sloppy at thinking and coding. Answering questions for careless and sloppy thinkers is not rewarding." - Eric Raymond