Can solutions be safely applied with new UD fields when the table in question has some existing UD fields?

I have created some new UD fields inside of some tables inside of a test environment. Some of these tables already contain some existing UD fields.

My question is this: If I wrap-up the affected UD tables inside of a new solution, how will it affect the target database when some of the UD fields contained in the solution already exist inside of the target database?

My concern is that re-applying a solution containing existing UD tables to the database might break something by either duplicating the redundant UD fields contained inside of the solution, or by over-writing existing data inside of the pre-existing UD fields.

Is this a valid concern? Or is the system smart-enough to never re-apply redundant UD fields inside of a solution?

I would test this for myself, but I’ve discovered that the Kinetic is rather unforgiving about restoring databases to slots which previously contained different schemas.

IMHO, and how I do it is: You should separate your solutions for the tables (zDataTable) and all the rest of the stuff. Because if the UD fields aren’t there when you try in install a solution that uses it will probably fail, and 2 if you want to install the rest of the stuff again later, you run the risk of removing fields that have been added since.

We don’t have this problem, but you do have to regen the model after you drop in the the copy to that slot.

Also, I should add, you can’t move individual fields. It’s the whole table, with all of the fields that have been added.

2 Likes

@Banderson
I am not wrapping the UD tables up inside of solutions which contain any of my customizations for exactly that reason.

I am talking about wrapping each of the affected UD tables inside of its own solution which would be both applied, and then regenerated before applying the separate solutions containing the customizations.

You’re fine then. If the UD field already exists, it will leave it there. We do this all the time. Just be aware, that if you delete and field, and put that table in a solution, so that field is not present, it will delete that field. That’s why old copies of the table are dangerous. Because if you add fields A, B, C make a solution X, then later add fields D, E, and F, and make solution Y, if you come back and re-import solution X, it will delete D,E, and F.

But fields won’t be doubled up. You can’t have 2 fields with the same name.

1 Like

I don’t import Ud fields at all from solutions.
I use the bo to apply from a script.

1 Like

Are you using the REST APIs to do this in your scripts?

No, I write an epicor function and pull from a dataset.

1 Like

I just did one the other day, but unsure if I saved it as it was a quick one off.

If I find it, I’ll post it.

Why do you do it this way @klincecum ?

To make sure I don’t screw up.

Not saying it’s the best way, I just like working procedurally.