old version cdt overwriting new data in the table

RE: old version cdt overwriting new data in the table

Arun Theja Muthyalu — Tue, 23 Feb 2021 20:22:19 GMT

@ankitab0001

Hello, I am not sure if you are still active on the forum. If yes, could you please let me know how you handled this scenario and what do you mean by data migration? Thank you in advance.

RE: old version cdt overwriting new data in the table

Mike Schmitt — Tue, 22 Oct 2019 01:57:57 GMT

I've heard of some plug-in which allows designers to update running instances with a new version in some way - but I've not personally used it so I'm not sure how extensively or how well it works (or even if it still works for modern versions). But it might be worth looking into, especially if the only thing that's changed for most models is the CDT version in question.

RE: old version cdt overwriting new data in the table

ankitab0001 — Tue, 22 Oct 2019 01:34:01 GMT

Thanks Mike. We have been doing the manual data migration so far which is not the best practice. Unfortunately, the WTDS node is in the running instances so can't even modify that.I think My best option at this point of time would be to cancel all the running instances and restart them. Any alternate solution is also welcome.

RE: old version cdt overwriting new data in the table

Mike Schmitt — Mon, 21 Oct 2019 13:19:20 GMT

I fear there is not a very clean solution for this. The one time I had to deal with something similar to this, luckily the particular CDT in question was always being written to DB in its own special subprocess which just contained the WTDS node -- in which case, i updated the WTDS subprocess to add a step right before the WTDS node to check whether the newly-added CDT field was empty, and if so, attempt to re-query the value of that column for that DB entry, before executing the update. Unfortunately if your WTDS nodes are directly contained in your already-running instances, then that means you'd need to edit instances manually to handle this.

Honestly I think your best bet at this point would be to keep a backup copy of what all the values should be, perhaps in a local file or perhaps in a separate database, and then each time a running instance finishes, either manually check it and revert the overwritten value, or create a special process to do this for you. If you have a single specific subprocess that always runs right at the end of a given legacy instance, for example, this could be a good target for an automated cleanup option.

RE: old version cdt overwriting new data in the table

ankitab0001 — Sun, 20 Oct 2019 22:22:16 GMT

Sushil Kapoor Thanks for your reply.

I am afraid, if I make the nillable = false, it would behave like a "required" field and it might break if there are any actual null values.

RE: old version cdt overwriting new data in the table

Sushil Kapoor — Fri, 18 Oct 2019 06:39:46 GMT

Hello,

Can you try by setting CDT-->Field attribute, nillable =false?

The nillable attribute of an element is retained. When a field with a null value is encountered, the element is not created.

Else need to handle by adding DB constraint.

Cheers