Solved

Violation of PRIMARY KEY constraint 'indx_pk'


Userlevel 4
Badge +11

After upgrading the SF to 2024.2 it comes up with the following messages when generating the definition, how to solve this?
 

Cannot insert duplicate key in object 'dbo.indx'.
icon

Best answer by Renée Evertzen 24 May 2024, 09:28

View original

7 replies

Userlevel 4
Badge +3

Hey Dennis,

Is there perhaps a situation that a developer has created a manual index, that has the same exact name as the one mentioned in the error?

There was an update regarding how the indexes are created in the latest release. This might create conflicts between specific indexes that were created manually, that are also created automatically by the Software Factory already.

Try deleting the ‘fk_ref_activity_customer_note’ index and then restart your definition generation.

 

Let me know if that helps 😊

Renée

Userlevel 4
Badge +11

Hey Renée,

Thanks for the quick response, however I have deleted several indexes but it seems to repeat for other indexes, I can hardly imagine these are manually created indexes.

See another example below:

 

Userlevel 4
Badge +3

To be honest, from the looks of your screenshot it does look like an index that has been added manually. If it concerned an index that was generated automatically by a base model for example, it would be light grey and cursive, as is the case with most generated objects. I can't be sure since I can't see the trace but I suspect that the generated by control procedure field is empty for that specific index. 

I would advise to go to model content, select the index tab page and filter on all fk_ indexes that aren't generated. Subsequently delete those and then check whether the definition generation still fails. 

If that doesn't help, feel free to send me an email so we can perhaps solve the issue together :)

Userlevel 4
Badge +11

Now it gets interesting, I removed the fk_ indexes (which were black instead of light grey) and re-generated them. Now the index is indeed light gray (not cursive) but it again comes up with the same message. So unfortunately this does not solve it.


The Trace info shows that the index is created by the control procedure “sql_create_indexes” but the checkbox generated remains empty. Can you explain when it is checked? Wouldn't it have made sense if it was checked now too?

 

By control procedure: sql_create_indexes

Do you have any follow-up suggestions or is this the point to investigate further by mail and share the outcome here?

Userlevel 4
Badge +3

Hey Dennis,

The data it shows is correct, the checkbox Generated doesn't have to be marked, just the option By control procedure showing the correct data is sufficient.

However, I did notice something else that is incorrect. Some of the procedures that are showing up in the list of procedures to be executed are not supposed to be there anymore in the 2024.2. This includes the one that is currently giving you problems, as well as the next 3. To summarize: only sql_create_indexes should be there. This is probably due to the nested base models not having been generated after the upgrade to the 2024.2.

If you check which base models are connected to your current work model and regenerate those, the obsolete procedures should disappear and no longer present issues.

Hope this helps! 😅

Userlevel 4
Badge +11

Hi Renée,

Thanks for the solution. It hadn't completely escaped my attention that the model needs to be re-generated, as this is clearly stated in your Upgrade notes 2024.2 - Re-generate model definition.

Where I went wrong (after all, I am also just a simple low-code developer) was that I was under the impression I could re-generate the linked Base Models from the current working model via: Model overview > Branches > Base models > Task - Generate definition. However, I have since found out that this is not how it works, as I would end up with the same error message every time because it would obviously try to generate the working model again.

 

After your response, I opened all 10 Base model branches one by one and executed the “Generate definition” task. This indeed solved the problem. Although this task only needs to be done during a Platform upgrade and not weekly, is this the correct approach for now and in the future? In my case, I have 10 Base branches, but I can imagine that with increasing numbers, this could become quite labor-intensive (though maybe I'm just a very lazy developer).

 

 

Userlevel 4
Badge +3

Hey Dennis,

To answer your question: Yes, currently this is the only way to do this.

However, it might be worth looking into whether we can make this a little more user-friendly in the future. If you want, you can create an idea for this and who knows, we might be able to pick it up when we're feeling particularly innovative 😉

Reply