Source Recovery

This Q&A forum allows users to post and respond to "How Do I Do ....." questions. Please do not use to report (suspected) errors - you must use your regional help desk for this. The information contained in this forum has not been validated by LANSA and, as such, LANSA cannot guarantee the accuracy of the information.
Post Reply
User avatar
lawingo
Posts: 56
Joined: Fri Dec 04, 2015 6:41 am

Source Recovery

Post by lawingo » Thu Nov 17, 2016 1:46 am

I accidentally deleted a Reusable Part both locally and on the Server. I have a good backup of all my production libraries. The object name is "FDHDW01". After looking through my backup I did not find an object named this but I did find "@FDHDW01". I restored this object but nothing shows up when I refresh Master Objects. Obviously, I'm missing something.

Thanks for the help in advance.

Chad
Sherrill Furniture Co

LANSAGuru
Posts: 68
Joined: Thu Mar 24, 2016 5:31 am

Re: Source Recovery

Post by LANSAGuru » Thu Nov 17, 2016 3:19 am

To get the object back in the repository you need the source code form the internal LANSA repository files. If the object exists in a different LANSA install or a different partition in the same install (I am not certain how you have your system setup here) you would do an export from production into a savefile and then import back into development from this savefile.

If you have only 1 LANSA install and 1 partition (implying you are calling production your server) then you will need to restore the entire LANSA repository from backup (save it off first so you can put it back). Then do an export of the object you are interested in. Then put the current LANSA respository back and then run the import from the savefile.

The LANSA respository is a library with the DC@____ files in it. This will typically be DCXDTALIB or DC@DTALIB, depending on the naming convention when installed.

You next logical question is, can I just restore a few of the files in question. That may be possible, yes, but I don't know the complex relationship between the internal database files (only the LANSA Product Center could answer this). It is safer to restore the repository as a whole.

User avatar
lawingo
Posts: 56
Joined: Fri Dec 04, 2015 6:41 am

Re: Source Recovery

Post by lawingo » Fri Nov 18, 2016 6:38 am

This helped. I didn't follow it to the tee but you got me in the right direction.

Many Thanks!

alex.otter
Posts: 1
Joined: Tue Nov 22, 2016 6:23 pm

Re: Source Recovery

Post by alex.otter » Tue Nov 22, 2016 6:27 pm

Thanks it helped me too.

User avatar
bill.yates
Posts: 1
Joined: Wed Nov 23, 2016 5:18 pm

Re: Source Recovery

Post by bill.yates » Wed Nov 23, 2016 5:26 pm

Lesson is always do a backup.

User avatar
Stewart Marshall
Posts: 417
Joined: Thu Nov 05, 2015 5:25 pm

Re: Source Recovery

Post by Stewart Marshall » Wed Nov 23, 2016 7:17 pm

Alternatively, make the move to using version control.
Stewart Marshall

Independent IT Consultant
www.marshallfloyd.com.au

User avatar
HMJust
Posts: 51
Joined: Wed May 11, 2016 7:23 pm
Contact:

Re: Source Recovery

Post by HMJust » Wed Nov 23, 2016 11:39 pm

Alternatively, make the move to using version control.
Which brings me to a question I've had for some time. We use a master on a system i with slaves on development machines. We also use a central slave SQL server "between" us and the master.
As far as I understand, we cannot use the file based version control in this setup. Is that correct?
I don't know what I am doing, nor how I did it. If it works, luck was involved :geek:

User avatar
Stewart Marshall
Posts: 417
Joined: Thu Nov 05, 2015 5:25 pm

Re: Source Recovery

Post by Stewart Marshall » Thu Nov 24, 2016 8:33 am

Your existing setup effectively shares a single repository instance between all developers. Any changes made by a developer are immediately picked up by all other developers.

Version control is just about the opposite view of development. All developers are independent and make changes in isolation. These are then checked in to the Version Control system, effectively making it the master, while the System i becomes a deployment target.

I spent many years writing LANSA applications (including the IDE) using a very similar model to you. We moved to version control a few years ago, and I'm amazed how we ever survived without it.

It takes a little work to get it setup and it takes a little getting used to, but it's well worth the effort.
Stewart Marshall

Independent IT Consultant
www.marshallfloyd.com.au

jyoung
Posts: 669
Joined: Thu Jan 21, 2016 6:43 am
Location: Oklahoma City, OK USA

Re: Source Recovery

Post by jyoung » Thu Nov 24, 2016 9:21 am

I greatly prefer using a VCS over a Slave.

At my last job we used a VCS with a lot of success, though we did have one small issue with deleting objects.

When I checked in an object and my co-worker pulled down the change and gets the latest version from the working folder,that object lives in both our repositories.
When I delete that object, populate the working folder and check in the change and my co-worker pulls down the latest changes, the physical yml file not in his working folder (as expected) and he gets the latest version from the working folder. It remains in his repository (not expected).
Then if he was not paying attention he could easily add that object to the working folder and subsequently check in the file that I had deleted. :shock:

Our solution was a team wide email whenever we deleted something. Then we knew when we got the latest version from the working copy that we should remove that file from the repository. Not fool proof but it was the best thing we came up with.

This was with V14, I don't know if SP1 solves it as I am at a new job and we are using a slave setup.
At least until I can convince them to go VCS. :D

Post Reply