Get History details of selected Ticket Number from table row having single table "TicketInfo"

This sounds like a somewhat complicated process flow made up of smaller, rather un-complicated segments.  As always I would suggest breaking it down into pieces and building it incrementally, starting with the most fundamental / most "required" element. 

In this case I would think the "most required" might be, "write a new ticket to the databse".  So you would want to get that working first, without worrying about the rest.

Step two might be, "get a list of ticket details that already exist in the database", perhaps in the context of a new process model / action.

Step three would then be, "select one of the existing tickets and load its data into the process for editing"

Step four, following that, would probably be writing the changes made, and whatever system (if any) you're using to store historic versions, could be added in at the same place.

If you haven't already, I'd start implementing this in phases and get back to us if you end up having any specific questions or troubles.  I must admit that most of us here probably don't have time to sit down and create a brand new process architecture for someone else completely from scratch, even if the temptation to do so exists for some of us.

Hi Mike,

Thanks you for steps details, I am could update record but not sure how to write  a historic version into DB/CDT. Probably need proper process model need to update to write historic version. 

Thanks,

Deepak

First you need to decide what your data structure would be.  Sometimes whenever a change is made, the current row could be left alone but deactivated, and a new row written with the new details.  Sometimes (if this might be happening a lot and you're worried about the table size), you could capture the changes and write those to a special table with the timestamps from the update and the user who completed it.

There's no one "right" way to do this, you need to decide what works best for you and implement it.

First you need to decide what your data structure would be.  Sometimes whenever a change is made, the current row could be left alone but deactivated, and a new row written with the new details.  Sometimes (if this might be happening a lot and you're worried about the table size), you could capture the changes and write those to a special table with the timestamps from the update and the user who completed it.

There's no one "right" way to do this, you need to decide what works best for you and implement it.