Packing a table from the control panel produces an error

[georgefurnel]

Good day,
I have just upgraded my v8 project to v9, and find myself in a bit of bother.

Packing a table using the �pack� command by right clicking a table in the control panel produces an error message �Could not pack or rebuild Indexes for c:\source\customer.dbf�s Dictionary�. The �update indexes command works fine� and the table is NOT open, I have checked.

I have now tried everything to resolve the issue but have now exhausted my ideas. What do you suggest I try? Unfortunately the error message is not very clear on what is causing the situation.

Kind regards
George

[martinwcole]

Re: Packing a table from the control panel produces an error

1) be sure the indexes do not include tables from a different adb
2) be sure the indexes don't have errors and note the indexes for later
3) create a new table from scratch, exact structure - append records from old to new
4) try to compact new
5) if successful so far, delete the old, rename new to old, add the indexes - try again
6) if all is not well - post back here

[DRW]

Re: Packing a table from the control panel produces an error

George, I happened to encounter this very same error yesterday with a table in an application I'm building. Likewise testing and rebuilding the indexes indicated no problems. I don't know what causes it or if there is a simple fix. In my case because the file that generated the error only contained test data so I gave up and just executed the empty the table utility, after which I was able to pack newly entered data with no problems.

I was going to suggest trying the append utility as well. I don't think using the duplicate table utility will work because you will simply be duplicating the same problem/corruption that exists in the original table.

[martinwcole]

Re: Packing a table from the control panel produces an error

if you use the append approach - you do NOT duplicate the table, you create a new table from scratch, and then append.

[Al Buchholz]

Re: Packing a table from the control panel produces an error

I was going to suggest trying the append utility as well. I don't think using the duplicate table utility will work because you will simply be duplicating the same problem/corruption that exists in the original table.

Actually quite the opposite is true. If there is a problem in the table structure files, a duplicate table clears up many of them. If it's a data problem, the problem will remain.

[martinwcole]

Re: Packing a table from the control panel produces an error

Al, you may be right - but my approach is to open the "bad table" structure - copy all the fields, make a new table and paste the fields in the new table, and then append the data. That way, I know there is no relationship between the tables's dictionaries. I know the table duplicate has options for not copying field rules, etc., but when I have this kind of a problem, I don't trust that some corruption from the "bad table" dictionaries might carry over.

Actually, there is also another thing that could be the culprit. Copy the folder containing the adb and paste to a new name - open the adb from the new folder, and try to compact the adb from the control panel - there is a known issue with no known cause, where you will get an error message from one folder, but not from another. I've had it in both V7 and V8. Only a few users have had the issue, I think.

[Al Buchholz]

Re: Packing a table from the control panel produces an error

Martin

Your approach is a good way to handle data corruption issues. The duplicate tables won't help that, but will narrow the problem away from the structure files.

Appending the data without field rules is a good way to find corruption..
ie a crlf() or other special character or letter in a numeric field. I definitely like that technique.

I've found all sorts of things in other dbase systems.

Another fun way to find bad data is to open a default browse and sort on each column. The bad data usually rises to the top, and sometimes the bottom...

[martinwcole]

Re: Packing a table from the control panel produces an error

Yeah, I've run into all sorts of nifty characters in the middle of data - especially when working with data from other programs.

[Bob Arbuthnot]

Re: Packing a table from the control panel produces an error

George,

You might check out this thread. It helped me a couple years ago, don't know if it applies to your situation or not...

http://msgboard.alphasoftware.com/al...ot+cannot+pack


Bob Arbuthnot

[georgefurnel]

Re: Packing a table from the control panel produces an error

Problem:
1. Packing a table using the “pack” command by right clicking a table in the control panel produces an error message “Could not pack or rebuild Indexes for c:\source\customer.dbf’s Dictionary”.

Observation:
1. When opening the table with the default browse, the column headings are truncated. Eg “customer_name” becomes “customer_na”

Steps to try to resolve (unsuccessfully):
1. Doing a database compact completes successfully
2. Made sure no tables are open.
3. Updated the dictionary with DICTIONARY.UPDATE()
4. Ensure that no “tablename.$$M” exist
5. Ensure that no indexes include tables from a different adb
6. Indexes rebuild successfully
7. Duplicating the table with all attributes, problem exists in new table
8. Duplicating the table with all attributes excluding records, problem exists in new table
9. Duplicating the table with all attributes excluding records AND indexes, problem exists in new table
10. Duplicating the table with all attributes excluding records, indexes and dictionary, problem exists in new table
11. Duplicating the table with no records, dictionary, indexes or field rules, problem still exist

SOLUTION:
Copy all the files to another folder. This is bizarre. I can reproduce the problem and the solution by simply recopying it. Thanks to Martin for providing the solution.

Later: no wait, the problem is now also in the new folder! Even duplicating the table to another without the records or indexes etc, still refuses to pack.


George

[MikeC]

Re: Packing a table from the control panel produces an error

George,
Your issue of truncation is one I had to deal with early on and every since then have never allowed myself to use names longer than 10 characters.

Now a lot of people have never had this problem and will say that it should not make any difference--to those I say yeah right!! :) There is one Big difference I have noticed between the people who have never had this happen and the ones who do: simply the difference between novice and accomplished. I firmly believe that this truncation comes from other corruption caused by bad code, calc expressions, what-have-you.

How to fix it--I only found two ways.
1...remember and rename all the truncated names back to what they were. And then later, after fixed, reduce the name size which in a large application is a real tedious process especially if any field names were used explicitly.

2...restore from a backup the affected tables and then change the names to shorter as above.

I really do feel for you if this Application has any size to it...took me the better part of 2 days solid to do when it happened to me.

[DaveM]

Re: Packing a table from the control panel produces an error

I really do feel for you if this Application has any size to it...took me the better part of 2 days solid to do when it happened to me.

Not so lucky. Found a few bugs from the shorter field names popped up several times over a month or so. Just did not catch all of them.

[martinwcole]

Re: Packing a table from the control panel produces an error

I'm sure you already know this, but just in case ...........

a table typically has 5 files, viewable from windows' explorer

clients.dbf - the data
clients.cdx - indexes and index definitions
clients.ddm
clients.ddd
clients.ddx

the dd*'s contain the layouts, field rules, and remainder of long field and index names

if you copy the dbf but not the other support files, you will lose the remainder of the long field names, etc., and they will appear truncated.

if you have good dd*'s from a backup, you can copy them from the backup and they will fix the truncated fields --- but they will thus also overwrite any layout changes, etc., you have made since the backup.

PS: just for the record - In using Alpha for 10 years, I have never had an issue with long file or field names. I have several apps distributed to several customes used daily for several years.

Also, whether the file or field name is longer than 10 characters won't make any difference if the dictionaries become corrupted, as the forms, field rules, etc. are also affected!!

[MikeC]

Re: Packing a table from the control panel produces an error

Martin,

Also, whether the file or field name is longer than 10 characters won't make any difference if the dictionaries become corrupted, as the forms, field rules, etc. are also affected!!

Makes sense, but one question to you or others---Why is it then that simply by renaming the truncated names back to the long names they were originally will make all errors vanish and everything is "normal" again until they become truncated again which can take a few days'weeks to happen??

(I realize that something is being corrupted and causing the truncation)

[martinwcole]

Re: Packing a table from the control panel produces an error

two possible answers -

1) everything is not okay, like the field rules may be messed up in one or more tables - you just haven't run into them yet

2) whatever the cause, it is only affecting long field/file/etc names

If 2 is the case, I would still be leary. As I understand it, and I may be incorrect here (hopefully someone will jump in,) everything about a given table is stored in the ddm, which is a memo field. the other 2 dd's are the index and table definitions that support the ddm. So ....... if that is correct, I would fear for the rest of it, if you see what I mean.