To Whom It May Concern,

We are having a discussion between our Baan developers, if something that is technically possibly with table definitions should be done or avoided.

We are having two VRCs, slog and seur, where seur is derived from slog. Occasionally, it happens that specific functionality is slog specific and the functionality will not be used in seur. This functionality can also include table fields.

One of our developers now argues that table fields should only be added to slog. If a table definition exists in seur, he suggests that the fields are not added there. This includes modifying all components in seur to exclude the new fields.

I disagree with this approach, because slog components are used in seur and this requires that all components that use the new table fields need to be copied to seur and modified to make sure that no fatal errors (missing table fields) occur. This adds extra components and the possibility that something is missed. New table fields that are added to a VRC should always be added to all derived VRCs.

Could you please comment on this and provide the official guideline that Baan developers should follow?

Yours,
Stephan

So, here are my 'thoughts'.

- This is a difficult question to answer, so I am making assumptions about what your environment is.

- Your derivation structure is:


standard
|
slog
|
seur


- So, you do not have any choice really - the fields you add to a table in slog will appear one way or the other in seur.

Say you add a field to some table in slog, then do a Runtime DD for that Package Combination. BUT at this time, do NOT do a Runtime DD for seur. For the time being, the new field is not seen in seur.

BUT, now let us say you have the need to add yet another field that needs to be in both slog and seur. So now, you do a Runtime DD of slog first, then of seur (to follow the heirarchy, as is required). At this time, the field you added the first time will appear now in seur also, in addition to the new field you just added. [It is always possible for someone to do a runtime DD on ALL tables of a Package Combination, and that would be that.]

- If this has been your build heirarchy for some time, it is too late to make modifications to the development process such as the one you describe.

- IF you really have to have the differentiation that you need, the heirarchy should be as follows:


standard
|
+-----+-----+
| |
slog seur


This will separate out the functionality, BUT it will necessitate carefully repeating the customizations that are common to both VRCs. If slog and seur are different customers, then this would have to be done anyway.

- That was about table modifications - in your heirarchy, the new fields have to be in all the VRCs in the heirarchy. As to the rest, it is possible, once the table structure is defined, to have forms or reports that do not use the fields that are not required.

In any case, you will need strict manual control so that no new modifications are start in VRC seur when there are modifications in progress for the same objects in 'slog'.

I would have to understand why you have the structure like you do to improve upon my comments.

shah_bs,

You are correct about our derivation structure, it is similar to:
standard -> slog -> seur

Originally, seur only had some additions and in general, all functionality from slog applied. Over time, seur has ended up with lots of extra functionality and extra table fields. This means that we have often a table definition in slog and one with more fields in seur.

One of our developers now wants to add new fields only to slog, but not add them to seur. As mentioned, it is technically possible, but is it a good idea?

Personally, I think that it is a very bad idea. We have already had problems in our production system twice, because this was tried and some components were missed, which resulted in fatal errors. Nevertheless, this developer argues that it is technically possibly and therefore it should be done.

I agree with you that if seur is not supposed to have the functionality that slog provides, then the hierarchy should be different, but this cannot be changed anymore.

From my point of view, with the given hierarchy, any fields that are added to slog should also be added to seur. If the specific functionality does not apply to seur, then it can be disabled in the seur code or controlled by a parameter.

Yours,
Stephan

You say it is not possible to change the hierarchy - but could you do this?


standard
|
slog Shared components for slog and seur
_____|_____
| |
| seur Only Seur specific components
nlog <-- New VRC slog specific components


In this method you just add a new VRC and point the company at that VRC.


From my point of view, with the given hierarchy, any fields that are added to slog should also be added to seur. If the specific functionality does not apply to seur, then it can be disabled in the seur code or controlled by a parameter.

I would do this if you can not change the VRC structure. At this point the developers get more burden as they have to code around the VRC structure.

Getting back to the subject. We have no intention to change our VRC hierarchy. The only question that I am trying to get answered is to tell, if it is a bad idea to introduce table fields in one VRC and exclude them from a derived VRC.

Hey Stephan,

There is nothing technically stopping you from doing it. And if you keep to the standard that the new fields have to have a default value - AND you never get lazy with your code so that you always call out your inserted fields. then you could, in theory, be fine.

seur -> Table X
Field 1
Field 2
Field 3

Insert into table x values ('1','2','3');
Success!

slog -> Table X
Field 1
Field 2

Insert into table x values ('1','2','3');
Failure!


But also -
seur -> Table X
Field 1
Field 2
Field 3 default '0'

Insert into table x values ('1','2');
Success! (just hope you weren't trying to insert into field 3 unless you specify the field names)

Or easier if you're on a baan version that uses DAL/DAL2 but of course it just keeps getting more complex to maintain.


So the big question - do you guys really have the resources and discipline to
to maintain this? and what happens when you all leave and find better jobs? sucks to be the new guys I guess...

;)

Dave

I guess each one of us, in his own way, is trying to say is that the new suggestion drastically modifies the software design and development procedures - this is not a good idea especially after the existing process (which works) has been in place for quite some time (as inferred by your decision not to modify the VRC structure).

The new approach needs a surgical change - I like Mark's idea better - it is more flexible than mine.

Many companies keep the table definitions at a single vrc level (corporate). This allows viewing or sharing of tables either with logical tables, or by changing companies. Once there is a difference in the data dictionary, changing of companies is not allowed. They then place the customized sessions in the derived VRC.

Some companies do have an additional development step for sessions that are customized for the additional fields. They will try to prevent the modification of data in the tables that do not have the proper customized session in their VRC, or to prevent the running of the customized session on company data that do not use the extra fields.