We need to add couple of new fields to the Purchase Order table.
I have two alternatives.
1. Add the fields to the standard table (tdpur040).
2. Create a new table (Primary Key = Primary Key of tdpur040 = tdpuro40.orno) and
add the new fields to this table.

What are the advantages/disadvantages?
I can think of the following.

# 1 : If I create a new table, future upgrades will be easier - no table level
customizations.
# 2 : If add new fields to the standard table, I do not have extra "shadow" tables in
the system.

Looking forward to your replies.
Thx

In this very specific case, I would advise to go ahead and add the fields directly to tdpur040 table definition. It will save you the additional headache of coding the selects in all the places where you need these fields whenever the PO is called ( - not to mention the logic (add/ update/ delete) that will have to be coded to keep the new table in sync with tdpur040). In fact, if the fields are informational in nature, you will not even have to code any maintainance logic, just put the fields on the Maintain PO form and you are done! As for future updates, tdpur040 is a simple table to 'roll over'.

The philosophical answer is: it is a case by case decision. Example, I would hesitate to add fields to tfgld410 table when it has 20 million records in it! It would take better part over the weekend to rebuild the table. (Not that I would not do it, either).


[P.S. Do not forget the tdpur050 (history) table and customizations to related libraries to correctly update tdpur050].

I work on the biggest Baan installation & development project in Europe, and we would never ever consider changing the baan standard tables. I suppose there is less danger of baan future patches to baan standard tables if you have Baan IV, as only fault fixing changes should be done in future by Baan and not lots of ongoing changes. Sometimes, you may still be forced to do extra select statements anyway, even if you do put the new fields on the existing tables, (not all selects in standard baan use the '*' to select all fields).

We have customized a number of standard tables. It has never been a problem. I think it all depends on what you want to do. If your change need to be visible in many places, it would make sense to customize the standard table. If it really only impacts a session or two, then the easiest path would be to make a new table.

I think this is one of those situations where everyone has an opinion and there is no absolute right or wrong answer.

If you have ever heard the expression, "If you don't have the time to do it right the first time, you won't have time to do it right next time." then you will use the shadow tables.

Baan does have a limit to the number of fields on a table. When Baan themselves reach a limit they usually split some of the info into a special table. On rare occasions customers have made additions to the Baan tables, and then was prevented from applying a patch because Baan also added fields. A limit was reached, and the customer eventually added a shadow table anyway.

Baan supplies conversion scripts when they split a table, or in the case of moving between versions, conversion programs between them. Having you changes in a shadow table makes future upgrades more acceptable to management when the decision to move on is being questioned.

The more "tied" to a version because of customizations you become, the more likely you will stop patching and upgrading, making you and your implementation obsolete.

Now what is your decision.... table change or upgrade?