Repository not saving work

Classic Servoy
1

I have a new release I started, and worked on yesterday. I come in today to find none of my changes in the new release saved. I seem to have lost that work. It was not a lot of work, so I figure something was up, so I deleted the release, saved and quit. I then restarted Servoy and created a new release. I did a little work in it, saved and quit. I open the release back up and again it did not save any of my work.
So now I want to see if has affected the current release the users are working on. So I again delete the release so that the top release is the active one the users are accessing. I add a button to a layout in the current release and quit Servoy. I open it back up again, and the button is not there. My repository is not saving any of my work.

I am at a loss. Any thoughts or suggestions?

2

Maybe an obvious thing but did you indeed activate the new release ?

3

No the most recent release is not yet actived.
I’m sorry, I should have mentioned that I am looking at this in developer by clicking on the newest release (unactived) and then click on load inside the repository.

Also, the repository resides on a MySQL database (3.23.54).

4

Only the latest release work will be saved and you can only work on the latest release when activated.

5

Wait a minute. This has all been working fine in the past. Let’s break this down a little.
The current actived release is 26.
I create release 27 and am going to do work on it.
I don’t want to active the release until I have made all my changes. So in the meantime, the users are on 26 while I am developing on 27.
Suddenly, I cannot save any of my work on release 27. So I delete it and try again. Same thing happens. Then I try to make a change on 26(the ACTIVED release). The same thing happens again, my changes are not saved.

This is my problem.

6

Hmm, I would never do that if I were you. It is advised not to develop on the same repository that is in production.

But I can not tell you why it worked and does not work anymore.

7

Ok. So let me ask this. If you develop from another repository on another box, how do you move the repository information over from one box to the next. Do you do a sql dump on the developer box and a reload on the production box?
The reason why I am asking is because I have never had good luck with keeping the release versions when I just do a export from Servoy on a developer box and then an import into Servoy on the production box.

8

The reason why I am asking is because I have never had good luck with keeping the release versions when I just do a export from Servoy on a developer box and then an import into Servoy on the production box.

Huh, that is the way to do it. It is designed for that and should give no issues.
If it gives you issues then please don’t work around but report it…
Or do I miss something here?

What do you mean when you say ‘keeping the release versions’?

9

It’s true that the release versions (the numbering) is or can be different than the release version on your developer machine (each developer or server has it’s own repository, so also it’s own releasenumber)

I think in a future release, you can give extra info to the release, so you can see, what version is installed on your live-server.
I do not know, in which release of Servoy this feature will be.

But not saving your work in the activated release, THAT I have never seen!.
If that was the case, I was in BIG trouble. :wink:

10

When ever I have exported a release from a developer box and put it in the production box, it puts it back to release #1. even if I use the import button and not the clean import. That’s why I have always worked on the same repository just the next release number.

11

When ever I have exported a release from a developer box and put it in the production box, it puts it back to release #1

I am stunned, never happened to me…
Only when you maintain different versions of a solution (not releases but really versions) this can happen. So are you sure you always export from the exact same solutions to the exact same solution?

12

Marcel,

He means the numbering of the releases.
If you have a solution with releasenumber: 23 it will become releasenumber 1 on a fresh installed server.

That has always been the case.

13

Aha, ok that makes sense doesn’t it :)

14

Yes. It buggs me when the release number does not transfer with the file. If that is the case, what good is the release number?

The way for me to get around this was to have my developer machine and production server look to the same repository.

15

yes, ofcourse it makes sense.
but it would be handy if we could give extra info to a release, so that we can see (exact) which version is installed on the live-server.

16

At least 3.5 is going to show the release date.

That will be a help at least…

17

So basically what I am hearing is that the problem may be caused by the fact that both my developer and live-server look to the same repository to get their information.
How about doing a mysqldump of a repository on my developer machine and an import into the production-live server repository? Would that work?
I’m thinking out loud here.

18

No don’t do that.

just export from you developer and import on your live-server.
because your sequence numbers of the PK in your table, can be different than the onces on your live-server

19

And just screw the fact that I don’t have correct release numbers on my live-server? I guess if that is the only choice I have …

20

Well, if I were you, I would not go that way.

I would think of a way to make this issue as workable as possible for your specific case and use Servoy the way it is designed.

What you want is certainly not supported and will almost certainly create problems.

No repository copying either because that can create sequence issues…