Extreme problem adding fields to a table.

[DaveM]

Re: Extreme problem adding fields to a table.

Thanks Stan.
Answered my questions and confirmed what I thought.

[Stan Mathews]

Re: Extreme problem adding fields to a table.

I would bet the ddm, but that goes with my lack of knowledge of the 3 files. I always suspected ddm wa actually a memo, ddx as an index and ddd is the other stuff.

Any body that knows better or can elaborate? I am all ears.

See post 36, this thread.

[Al Buchholz]

Re: Extreme problem adding fields to a table.

One of the 'magic' tricks for structure corruption is to duplicate the table/set and choose all the options (data-fieldrules....)

Then test on the duplicate and usually the problems disappear...

Then get rid of the original and rename the new table to the original table name..

This seems to work when a data dictionary compact doesn't work...

And since you have a backup with the problem, you could test that theory and report back....

[DaveM]

Re: Extreme problem adding fields to a table.

I would bet the ddm, but that goes with my lack of knowledge of the 3 files. I always suspected ddm wa actually a memo, ddx as an index and ddd is the other stuff.

Any body that knows better or can elaborate? I am all ears.

[preston2]

Re: Extreme problem adding fields to a table.

Did you determine where the corruption existed? Memo field, field rule, bad data, etc?

It was in either the wo_header.ddd , wo_header.ddm or wo_header.ddx file

I took an older copy of those files and included them in the update instead of the newer ones. During the update the fields where added to the wo_header.dbf without any problems. I then added the few field rules for the new fields.

I then used these files in the next test update and everything worked. Fields where added, all field rules where there.

I never did find out which one of those 3 was corrupted just enough to not allow any fields to be added using a function as you cannot just replace one at a time. If you do Alpha will not start and gives a missing field rule error so you have to change all 3 at the same time.

[Stan Mathews]

Re: Extreme problem adding fields to a table.

Did you determine where the corruption existed? Memo field, field rule, bad data, etc?

[preston2]

Re: Extreme problem adding fields to a table.

Tracked the problem down to at least 1 corrupt file out of 3. Rebuilt those files and all is well.

So it turns out nothing was wrong with the code at all.

And I am now compacting my dev database although I now keep extra backup copies instead of the normal 2 copies just in case.

[DaveM]

Re: Extreme problem adding fields to a table.

99% of the time with new fields in tables for a remote client:
I use my installer to:
backup the old application completely to another NEW folder.
clear the install folder
install the files - 1st adb/dbfs/fpt
run the 1st adb that will append all data from the backup and do any other needed
install the true adb and all support files for the tables and the sets. Basically everything but the dbf/fpt files

Client should be good to go at that point because I have fully tested the install on several computers before the send.

minor - one or 2 table updates can be handled similarly, but not such a big operation.

[G Gabriel]

Re: Extreme problem adding fields to a table.

I ran your script on my system and had no problem with it. There is/are other external factor(s), scripts before or after that is causing this to happen. Without seeing the entire scheme it would be impossible to figure out what is happening.
As an alternatives, you might try:
1-table_restructure()
In which case, you gather the existing fields, add them to the new fields and restructure the table.
Or,
2-Duplicate the table structure. Just the structure. Then add the new fields to the new table, append all records to the new table, then rename it to the original table.
Of course, you need to backup first.

[preston2]

Re: Extreme problem adding fields to a table.

Tom, the function I use is based off the ones I got from Cal a few years back. I have never had a problem doing it this way.

I also did try just adding one field and it still did not work right.

[Tom Cone Jr]

Re: Extreme problem adding fields to a table.

Preston,

Your function adds a list of "new" fields to the table in one step.

Most of us handle this differently.

We create a list of the "existing" fields in the table.
We create a list of the "new" fields we want to add, if they're not there already.

We do it one "new" field at a time, like this:
- step through the list of "new" fields and for each...
- check to see if the current "new" field is already in the table, if so do nothing
- if not, then add that one field to the table and loop back to the "next" entry in your "new" field list
- repeat until all the "new" fields have been checked and added or skipped.

Of course, this entire sequence must occur while the script has exclusive read/write access to the table, so checking if the table is in use first is a pre-requisite.

Adding new fields one at a time makes it much easier to figure out what happened if an error occurs.

Hope this helps.

-- tom

[preston2]

Re: Extreme problem adding fields to a table.

Get a cup of coffee.

Now that is some good advice. Off to make a new pot now.

[DaveM]

Re: Extreme problem adding fields to a table.

I compact about 3 times a day on average with a very large app. as soon as stuff starts going a bit goofy and a bunch of changes - compact.
Get a cup of coffee.

[preston2]

Re: Extreme problem adding fields to a table.

Well the copy table will not work on the wo_header.dbf either. It is like it cannot see fields that are there.

Guess it manually fixing all the customers stuff time.

[Stan Mathews]

Re: Extreme problem adding fields to a table.

I understand your aversion to the issues which can arise with compacting a database with a corrupt memo file. There are discussions elsewhere about moving all memo fields to a table containing only a linking field and memo fields and then creating a set with a one to one link to the "parent" table where the memos were originally. I don't know if anyone still does that but the benefit is that should there be memo corruption only the child table is involved, not the other.