Chris21 has built in functionality that allows you to do your own customisations. It’s a very useful tool and one that you have probably already taken advantage of. Chris21 customisations mean user defined changes to files, fields or forms. These changes can affect Chris21 or other interfaces, such as HR21.

Before I go further I would like to say that you do need to know what you’re doing if you want to delve into this area of Chris21. I would recommend some form of customisation training if you are not experienced.

If you have some experience with Chris21 customisations, you will understand the concept of the system and user areas of a file. I talked about this briefly in my blog Customising Chris21 – What Can Go Wrong? From my experience, it is the misunderstanding of this concept that causes the most issues with customisations. Many Chris21 systems I see have been customised in the system area of the file. In other words, existing fields are changed so that they can be used for different purposes.

It’s quick and easy to take an existing field and change some attributes to suit your purposes. Unfortunately this approach can cause you problems in the future.

So what’s the problem with this? The main problem is that if you use the system part of the file you can’t be guaranteed that system upgrades will not affect your customisations. There is the risk that a field that has been changed in the system area to suit your purposes may be overwritten by an upgrade. This could manifest itself as overlapping data or overlapping labels on forms. Even worse, if you have changed the data type of the field, say from an integer to a date, you may encounter errors when trying to update records.

What’s the best way to avoid this? Use the user area of the file. This area has been especially created for you for customisation purposes. The user area size is usually 120, meaning you can add fields up to a total of 120 characters onto the file. Importantly, any changes made in this area will not be overwritten during upgrades.

Keep this principle in mind when you undertake any Chris21 customisations. It will help to ensure the integrity of your database and give you less to worry about come Chris21 upgrade time.

The post Chris21 Customisations – Do it Right! appeared first on System Logic.

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.

The post Customising Chris21 – What Can Go Wrong? appeared first on System Logic.

I want to bring your attention to the Field field on FLD. If you are customising Chris21 and want to add a new field you must take care when choosing the Field number.

You will find that you can enter any number you choose into this field. Therefore it may seem like an arbitrary number that is of little significance. The most important point is to ensure that you do not enter a duplicate Field number.

When you look at the list of Field numbers in the screenshot above, you will notice that there are no duplicates. Ideally you will create new fields in ascending Field number but this is not critical. But what is critical is that you don’t use a number that has already been used. Unfortunately, Chris21 will let you use a duplicate number without flagging an error. So you could do this by mistake without noticing.

What is the problem with using duplicate Field numbers?

When you use a duplicate Field number Chris21 will only display one of the fields on your form. Therefore, even though you may have correctly placed your new field at a different position on your form, the original field will no longer be displayed.

The easiest way to avoid this is to identify the highest field number that has been used on the form you are customising. You can do this by searching for the Form Identifier on FLD as shown in the screenshot above. Then simply use the next available number.

Keep this tip in mind when customising Chris21 so that you will not mistakenly remove fields from displaying on your forms.

The post Customising Chris21- Hidden Fields and Field Numbers appeared first on System Logic.

If you are customising Chris21 forms there are two processes to consider. The first is the Data Dictionary (DMA) where you create the field on the Chris21 file and the second is Field Definitions (FLD), where you place your newly created field onto the Chris21 form. Last week in my blog Customising Chris21 the Right Way I discussed the first part of the process.

The key point of last week’s blog was to ensure that you create the field within the user area of the file so that your customisation will be safely retained after future upgrades. Failure to do this is probably the most common cause of customisation issues.

To complete the second part of the process, go to Field Definitions. Using the example from last week, we will place the field POS GRP NUM onto the Positions (POS) form. You will need to determine a few things before you start.

Firstly, decide where you want to place the field. Usually this will be under the last field on the form. If you want to place it in the middle then you will have to move all of the fields below your insertion point down one line. I usually will just add the new field after the last field for the sake of convenience. Look at your Positions form and note the last field:

In my example, the field is Review Type.  Now go to Field Definitions, select Ctrl F and type POS in the Find dialog box. From the list, find the field called Review Type:

Look for the column called Label Row. This will tell you which row Review Type is placed on. In the screenshot above the row is 27. Our new field will therefore go on row 28.

You also need to identify an appropriate field number for your new field. Be careful here because if you choose a field number that is already in use then either your new field will not be displayed or the existing field will be hidden and replaced by your new field. From the screenshot below look for the highest field number in the Field column and then add one to this number. This is the field number you will assign to your new field.

The highest field in use in our example is 49. We will use field number 50. You can now create the record to place your new field on the Positions form.

Go to Field Definitions and click New from the main menu. Enter the details for your new form as shown below:

You can see that I have used number 50 for the Field field and number 28 for the Label Row. Note also that the Data Row must also be 28 to ensure that your label and data are on the same row!

That’s all you need to do to create a new field on a form. To see the effects of your changes you will need to clear cache in Chris21. Notice that Group Number is now on your form under the Review Type field:

If you clear cache and still don’t see the changes try logging out and then back in.

This blog, along with the information in my last blog Customising Chris21 the Right Way will give you enough information to begin experimenting with basic Chris21 customisations. Of course, you should only do this in your test system until you become familiar with the process. Give this a try and let me know if you need any further information.

The post Customising Chris21 Forms – How to Place a Field onto a Form appeared first on System Logic.

I have written in the past about customising Chris21 and how to do it properly. From my experience I have seen many examples of bad customisations and have helped clients to fix these so that they don’t continue to cause problems in the future. My blog Chris21 Customisations – Do it Right, talks about this issue and explains the sort of problems you can experience with bad customisations.

The wrong way to create a new field in Chris21 is to take an existing field and use it for a different purpose. I can’t emphasise this enough. Sure it’s easy to grab a field that’s already there, rename the field and maybe even use it to store text rather than a numeric value. But it’s not that hard to create a new field either. Let me explain.

I will use the example of customising Chris21 by adding a new field onto a form. I always recommend that whenever you are customising Chris21 that you start in your test environment. Once you have done this and tested the results, you can then copy your changes into the production system.

The first thing to understand is that there are two areas on each Chris21 file, the system area and the user area. You don’t want to do your Chris21 customisations in the system area. I discuss this in my blog Customising Chris21 – What Can Go Wrong?

Your starting point is to find the start position of the user area of the file. You do this by viewing the File Table (FIL) entry for the Chris21 file you want to customise. As shown below, there is a field on the File Table entry called User Area Start.

In the example above, the User Area Start number is 1133. We will use this number later when we create the new field. The other important field is the Storage Size. In this example, the Storage Size of the EMPOS file is 122. This means you can add multiple fields to this file to a combined total of 122 characters.

Even though we can see that the User Area Start number is 1133, it is nevertheless very important that you confirm this before creating a new field in this location. You confirm this by reviewing the Data Dictionary (DMA) entries for the EMPOS file. To do this, go to DMA and from the list of Field Codes create a Quick Filter where Field Code equals EMPOS.

This will display all of the fields that are included on the EMPOS file. You must review all of the start positions to confirm that number 1133 hasn’t been used by previous customisations. If it has, keep looking in case there are more customised fields after 1133. When you have found the highest start position number that has been used in the user area, remember to add the field Storage Size onto this number. For instance, if the highest start position number is 1148 and this field’s Storage Size is 6, then the next available start position number is 1154.

Once you have the start position number you can begin to add your new field. Open DMA and click New from the main menu. A typical DMA entry that has been created for a numeric field is shown below.

As you can see, this field has been created at start position 1133 which is in the user area. If you wanted to add another field the start position will be 1135 – 1133 plus the 2 characters that the previous field used.

You now have a customised field that will not be adversely affected by future upgrades to Chris21. If you ensure all of your customisations are done this way you can be confident that customisation issues will be eliminated in future system upgrades.

This can be a difficult area if you have had limited experience customising Chris21. Leave a comment and let me know if you require some more information on this topic. In my next blog I will demonstrate how to place this new field on the Positions (POS) form ready for use.

The post Customising Chris21 the Right Way appeared first on System Logic.