Dealing with Read-Only Columns in the Excel Add-In During Data Migration
- Martin Surasky
- 1 day ago
- 5 min read
Introduction
When working with the IFS Excel Add-In for data migration, one of the first hurdles many encounter is the presence of read-only columns. At first glance they look like ordinary fields, but the system refuses to let you update them directly.
One of the trickier challenges that pops up during data migration with the IFS Excel Add-In is dealing with views that contain those read-only columns. The problem isn’t usually that you want to update those fields — you know they’re locked down for a reason. The issue is that when you try to update other, perfectly valid fields on the same view, the Add-In sometimes refuses to cooperate. It interprets your update as an attempt to modify the read-only columns, even though that’s not your intention. This mismatch between what you want to do and what the tool allows can bring a migration to a halt unless you know how to handle it.
Understanding why these columns are locked down, and how to work around them safely, is an important part of running a successful migration.
Understanding Read-Only Columns
Read-only columns in IFS are not there to make life harder, even if it sometimes feels that way during a migration. They usually serve very specific purposes in data management. In many cases, these fields are populated automatically by the system — for example, audit information like creation date, last update time, or the user who performed a transaction. Other times, they represent derived or calculated values, such as totals or status flags, that shouldn’t be directly altered by end users.
Another common use case is when a field is tied to business logic that enforces data integrity. By keeping those columns locked down, IFS ensures that only the system — not a manual update — can maintain consistency across related records. In short, read-only columns exist to protect the validity of the data and to reduce the risk of accidental or unauthorized changes.
Practical Example of Data Migration
To better understand how read-only columns complicate a migration, let’s look at a real-world example. Suppose you’re working with the CUSTOMER_CREDIT_INFO view and the task is to migrate information into the CreditComments column for a large set of customers. At first glance, this seems straightforward — just set up a migration job, point it at the right view, and load the data.
The context and goal here are clear: you’re not trying to update any sensitive or protected data, only to add or adjust the comments that help track credit-related details for each customer. However, because the view includes read-only columns alongside CreditComments, the Excel Add-In introduces unexpected hurdles.
To begin, you create a migration job in IFS. In the setup, you enter CUSTOMER_CREDIT_INFO as the view name and set the procedure name to EXCEL_MIGRATION. I'm leaving PARTY_TYPE and PARTY_TYPE_DB on purpose so you can see I'm passing Default Values that match the PARTY_TYPE a Customer should have. Again, I don't intend to modify anything on those fields, only keep the existing values.
You then configure security (remember the Projection being allowed to the Permission Set?) and a few other configurations that I will not detail here as the main purpose of this article is to show you how to solve these issues and I don't want to make it an "Excel Add-In Tutorial" instead, so without losing focus, let's go back and see that finally the Excel Add-In generates the template, showing all the available columns in the view, including those read-only fields. With your data prepared and mapped into the CreditComments column, you’re ready to push the migration — but that’s when the issue with the read-only columns starts to surface.
After the setup is complete, you switch to Excel, fill in the CreditComments column with the data you want to migrate, and then hit the Validate button. Instead of a smooth confirmation, you’re met with the dreaded error message:
ORA-20122: [column in view] may not be modified
In this case, the error points to PartyTypeDB, a field in the view that is marked as read-only. The confusing part is that you didn’t touch that column — the value in your spreadsheet is exactly the same as what already exists in the database. You’re not intending to modify it at all.
This is where the Excel Add-In behavior becomes problematic. Even if you try to remove the column from the Migration Job Definition, or explicitly set a default value that matches the existing data, the Add-In will still attempt to include that column in the UPDATE statement. The end result is the same: the system believes you’re trying to modify a read-only field, and it stops your migration cold.
Step-by-Step Approach to Handle Read-Only Columns
Without further Ado, these are the changes you need to include in your migration job to solve the problem
Go back to your migration Job and navigate to the Method List tab. You should see (in this case) a single entry for the CUSTOMER_CREDIT_INFO view.
Click the "three dots" button on that Method List entry and select Method List Attribute.
Once the Method List attribute, notice that the On Modify for the PARTY_TYPE_DB colum is set to Yes.
Edit the form and flip that switch to No
You will notice that right after saving that change you can go back to your Excel Add-In entry and Validate again. This time Validation should work.
Also, you can now execute your migration and see the results as you expect. The field we intended to change (CreditComments) has been migrated and Party Type is no longer getting in the way.
Conclusion and Results Achieved
There is no clear indication before getting into a migration job in Excel (or any other type of migration for that matter...) that you are going to be dealing with these types of fields. Sometimes, your own experience will help you to realize you are getting into these types of issues before you even finish creating the Migration Job. Many senior technical consultants who, like me, have done a substantial amount of migrations on Customer or Supplier data know that PARTY_TYPE_DB is a non-starter when migrating changes.
Even if you don't know that, you can always try to run a subset of your changes and validate. If you find a message similar to the one we described here (ORA-20122) you can use the same troubleshooting here to address whatever read-only field may get in the way. Be careful, the exact message returned by IFS may be slightly different (it would even have a different ORA code) but if you suspect that the root cause of the error is that you are inadvertently trying to modify a read-only field, try switching this setting on that field and see if the error goes away.
Final Thoughts
Read-only columns can be a frustrating roadblock during IFS data migrations, especially when the Excel Add-In insists on treating them as part of your update even when you’re not touching them. As we’ve seen, this behavior can derail an otherwise straightforward task, and it’s important to understand not just why these errors happen, but also how to work around them in practice.
If you’re facing similar challenges with Excel migrations in IFS, you don’t have to wrestle with them alone. As a technical consultant, I specialize in helping organizations streamline their migration processes and avoid the pitfalls that come with tricky views, read-only fields, and Add-In quirks.
Feel free to reach out — whether you’re planning a migration, stuck in the middle of one, or just want to build confidence with the Excel Add-In. I’ll be glad to help you get your data where it needs to be, without the unnecessary headaches.