Hi, we very rarely have any problems with Servoy…
Today, when editing a solution in 2.2.5, we get a
‘Cannot Save Solution’ window, with the following message "org.postgresql.util.PSQLException: ERROR: duplicate key violates unique constraint “servoy_elements_pkey”
The new stuff we add keeps disappearing after a Servoy restart.
Looks like Servoy is not generating unique ids for new elements when saving… any way to reset/fix?
Additional info. We may accidentally have edited a module on two computers simultaneously.
swingman:
Additional info. We may accidentally have edited a module on two computers simultaneously.
What happens if you remove the module from the solution?
Riccardino:
What happens if you remove the module from the solution?
That is a good question, it is fairly central to the solution so I’m not sure it is possible.
Christian
Have you tried going into Define Dataproviders, selecting ‘servoy_elements_pkey’ then Properties / Sequence and “Synch with DB”
This should stop the duplicate key messages.
Regards
Graham Greensall
Worxinfo Ltd
This problem should not occur, even if you accidentally work on the same repository with two developers. Did you do anything strange? (Like restart the postgres database while one of the Servoy Developers was kept online?)
The official way to solve this problem is to export all solutions, make a new repository, and then to import them again into the new repository.
The unofficial way to solve this problem is to backup your repository and not come running after me after everything breaks and to execute the following queries on your repository:
select max(element_id) from servoy_elements;
update servoy_object_types set next_seq = <the max element_id + 1> where object_type_id = 13;
Again, no warrenties, use at your own risk…
select max(element_id) from servoy_elements;
update servoy_object_types set next_seq = <the max element_id + 1> where object_type_id = 13;
This shows the great design of Servoy 
– I took a quick look at repository tables and worked out that one on my own – except that the next_seq value looks ok… so I didn’t do anything to it.
Have
I just recalled, also make sure it’s greater than the max columninfo_id from the servoy_columninfo table, since they share the same sequence.
SELECT next_seq FROM servoy_object_types where object_type_id = 13;
= 12435
SELECT max(columninfo_id) FROM servoy_columninfo
= 12409
select max(element_id) from servoy_elements
= 12431
So it looks OK.
Have just exported, will create a new repository and see if this fixes the problem.
Hmm… I find it very strange. It looks ok indeed. And it still goes wrong? Are you absolutely sure that you are connected to the right repository database? Because Servoy never inserts anything in the primary key of servoy_elements other than the sequence which it finds in the object_types table. And since that one is right, the next insert should definately be ok.
I’m just organising a reboot of the computer running PostgreSQL to see it this helps.
Still stuck - trying to see if this is a database problem or a Servoy problem. The repository runs on PostgreSQL 8.1 on Windows 2003. Latest version is 8.1.4. Moving it now to PostgreSQL 8.1.3 on Mac OS X to see if the problem goes.
No luck. Same problem. I exported the solution and tried to reimport and it fails with the same error message.
The problem has suddenly disappeared. Tried creating methods in other modules to see if all modules were affected – no problems found. Went back to the affected module and it now saves fine…
Did you reimport into a clean repository?
If you send me a dump of your repository with pg_dump -Fc I’ll have a look at why it is corrupt.
Hi, I logged the whole thing in the support system.
Will send you the file.
Hi,
I’m still trying to figure out what caused the problem in the first place. Did you at any time start/stop the repository server database while keeping Servoy running? Or switch from one repository server to another while Servoy was running?
Hi Sebster,
We generally leave the databases on 24/7… we really have no reason to restart Postgresql ever 
We have one repository per project and in some cases on local development repository and one remote production repository. As we have separate servoy_properties for each project, there should be no reason to switch repositories around.
There is sometimes several developers running on the same Mac… and we move modules around between projects.
We do occasionally switch database servers around to work around mySQL servers which have gone offline…
I haven’t tried exporting the whole project for a while…