CiviCRM Community Forums (archive)

Thanks Hershel, if I understand correctly, in that scenario, the only existing path (in 4.05) would be to add a new (named) field to a new group or custom data set, then use an existing set of multiple choice options ( for example, the ones already created for county names), then delete the other (old) field.

Yes

Presumably you could slightly alter the name though, for example to "Member_County" instead of "County" and employ the existing multiple choice set, is that right? This is presuming the spreading of multiple custom data fields (with many options) over different groups is the solution here.

Correct. The site I have does just that because they have the same named field in several groups.

If deleting a field fails, you could try manually. You must remove the record in the table civicrm_custom_field and then the field itself from the custom data table.

hmm, i think if u get to point 3, civicrm is already hosed with regard to that table. U'll then need to manually delete the custom field from the database

ideally, we should detect the error and if an errror occurs, basically not make any changes. If you have developer resources would be great if you can get them to look at this, might not be too hard. We can help them get started (the code is fairly localized)

lobo

As we are re-creating the fields, just noticing that we have a notes field with no set parameters, ie height, column height ...Peter had mentioned something similar in an earlier reply -- is a notes field something that would break a table? any one have an idea what the optimal or maximum height/width should be?

well, things have taken a turn for the better!! We created new custom data duplicate fields, ie, field_duplicate for each one. We still can't delete the old ones (which are of type "contact") in the offending "members" custom data set, as we get this ugly error for each of the "non-deletable" old fields : ""DROP COLUMN `cdla_issued_73` [nativecode=1091 ** Can't DROP 'cdla_issued_73'; check that column/key exists]"

(point of note : cdla is the name of the particular license for which we need such date fields, and we get the error for each of the old fields)

However, doing an import into the new custom data groups (sets) of license fields, grouped more modestly in terms of their overall number of fields actually works (!) thanks to the advice above

This means that it may be possible (?) to simply leave the previous offending fields there and not delete the whole data set  -- which would mean we can preserve about 2200 records or so that have all sorts of related member info in there. Of course if we have to reimport everything we will.

I should also note that other non-license fields in the offending set CAN be deleted.

So does anyone think we can get away with just manually deleting (in the dbase) the offending custom data fields and leaving the other fields that seem to be "non-corrupted" in the offending group...we want to save work but obviously don;t want to leave the client a loaded minefield of potential bad code 

So far so good with this, thanks for all the help above. As of now, we've simply disabled the offending fields, created duplicates and spaced them out over 4 groups and successfully imported the custom data (all date fields) in. this allowed us to leave the already migrated info in the previously imported members fields.

For the moment we'll hold off on any additional manual deleting in the database, which may be somewhat a roll of the dice but things appear stable so why mess it, at least until we stumble again.

Strangely, we never hit any kind of limit with the characters in the notes, though we had a lot of them, knock wood.  We've got some additional membership stuff to configure, but as of now looking good. thanks again everyone who offered assistance...H