Visual LANSA Forum

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

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.

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

Many Thanks!

Thanks it helped me too.

Lesson is always do a backup.

Alternatively, make the move to using version control.

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?

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.

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.

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.