RE: Ref. : Removing columns in a table


RE: Ref. : Removing columns in a table

Instead of carrying these extra columns everywhere, we would put them at the
item master level as new attributes of a product.

I know it's very dangerous, that's exactly what I told my boss. I thought
that maybe somebody somewhere went through this already and had a little
magic procedure that I could use.

I wanted a second (or third or fourth) opinion to convince my boss that it's
really not a good idea.

Thank you for your input,



RE: Ref. : Removing columns in a table

If you have described your problem accurately, Sylvie has the right idea.
If you have a column included in your custom table that you no longer need,
It will not be either wise or cost-effective to remove the column from the
table just because you've decided that it isn't needed anymore.

Instead, I would recommend eliminating the display of the column on the
screens and reports you can identify, and disable editing on the column on
any maintenance screens or batch update programs. You'll have a blank space
in your table, but you may find a need for the field at a later date. .
Also, failing to identify an object that uses the table won't render the
object unusable. If you actually remove the column from the table, any
object using the table you forget to revisit afterwards may be unusable
(bad) or quietly deliver the wrong results (worse).

If the column has been defined as part of the primary key, the field could
still be left intact as long as it is consistently filled with the same
value in each record. This could become confusing later when maintaining
your applications or adding new applications, however. Is the field a part
of the primary key?

Drew Reilly, CPIM
Reilly Consulting Corporation


VIP Member
RE: Removing columns in a table


I have gone through this scenario. Changing the dependent objects was
fairly easy. We did worry that we might miss an object or two. The trouble
we had involved actually changing the table itself without losing the data
and without disrupting the users.

Before changing the table, we had to store the data in an auxiliary table.
Then upon regenerating the table to the new specs blows away the data so we
then move the data back into the new table. All of this was timed so the
users never had the wrong specs. So a deployment had to be scheduled around
the table change. Changing tables is more of a pain logistically than
anything else so I avoid it when I can.

Ben (again)


Well Known Member
Re: RE: Removing columns in a table

Hi Sylvie,

Do you have any BF using API record level operations on that table (“JDB_FetchKeyedForUpdate” for example)? You have to double-check that nobody hardcode column name and numbers of columns and fix that. In any case you need to regenerate every object related to that field, build and deploy package update contains all involved objects (don’t forget to save data somewhere and repopulate table after). How much time you will spend? Is that hard drive space you will save worth all of that work?

Best regards and good luck.