There’s plenty that can go wrong when you start customising Chris21. I’ve seen a lot of Chris21 databases and, for the most part, the only ones that I would describe as ‘clean’ are the new ones.

The new ones are good because no one has started to play around in the data dictionary yet. On the other hand, it’s quite common to see older databases with many customisations – good and bad.

So should you customise your Chris21 database? And if you should, how do you go about it to ensure that your database is kept clean?

What does customising Chris21 mean?

In the context of this blog, customisation means changing your Chris21 data dictionary. This can be as complex as adding a completely new form, or more simple tasks, such as adding fields to an existing form, or removing or renaming fields.

There can be lots of reasons for doing this and some very legitimate ones. Sometimes you will need to customise to meet business requirements.

Before I go any further, I want to point out that I am not against customisation. I just like to see it done the proper way.

What are the fundamental customisation sins?

Chris21 has been developed to be customisable. This allows clients the flexibility to change their database to better reflect their business. This is a good feature.

The thing that’s not so good about it is that there is a right way and a wrong way to go about it. When it’s been done wrong you will know it when you upgrade. Ever seen overlapping labels or data on forms after a Chris21 upgrade? Ever seen labels or fields disappear completely after an upgrade?

Bad customisation is usually the culprit. Here are some examples of customisation gone wrong:

1. Ignoring the user area

This is the main issue I see and it causes lots of problems. The user area is that part of the file that has been set aside for customising Chris21. We are assured by the vendor that they will not touch the user area of a file during system upgrades. Use this area only and you shouldn’t see the problems mentioned above, such as overlapping data.

2. Hijacking fields

This is the term I use when the structure of an existing field is changed by a customisation. For instance, taking a text field and making it numeric. Or making it table validated. Here I am talking about a standard system field, so it’s one that the vendor can choose to alter at any time.

I see a lot of this. Probably because it’s an easy fix. But what happens if the vendor does change that field -perhaps making it larger? After the upgrade your field may not look or function as it did.

3. Using duplicate field numbers

Field numbers are important. You can’t have duplicate field numbers because only one of the fields will be displayed. The one that will show is the first one alphabetically by field code. But this might not be the one you want.

If you use a field number that is used by another field, you might find that field disappears when you upgrade.

4. Customising in database mode

By this I mean in SQL or Oracle if you are using one of these database options. Some people may do this but I think it can lead to problems.

Remember, you might be changing the structure of a file. You might be storing data as numeric when it was text. It’s safer to move the file into Vision mode before starting. That way the table is rebuilt fresh when you move the file back to the database.

How do you ensure you are customising Chris21 right?

If you are thinking about customising Chris21, ensure you have a good understanding of how to go about it. Then do it right by avoiding the pitfalls mentioned above.

If you’re not sure then get some help. It’s taken me many years to become proficient at this – it’s not something you will learn overnight or by attending a course – although, granted that will help.

Spend some time after an upgrade fixing the problems. These will keep recurring if you don’t fix the root cause and can be very time consuming.

Do you have any issues with your customised database? You may have found similar issues to those mentioned in this post, or you may have something else to add. Let me know by writing a comment, I would be interested to hear other perspectives.