Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Error installing package. FK_KEY constraint
-
Following error occurs quite a lot in our Proget server, which is working very nice but has been acting up after the latest update.
Message:
Error installing package: 547`16`0`Packages_CreateOrUpdatePackage`111`The INSERT statement conflicted with the FOREIGN KEY constraint "FK__Symbols__Packages". The conflict occurred in database "ProGet", table "dbo.Packages".
Stacktrace:
at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo) at System.Environment.get_StackTrace() at Inedo.ProGet.Diagnostics.DatabaseErrorMessenger.Inedo.Diagnostics.IMessenger.Message(IMessage message) at Inedo.Diagnostics.Logger.Message(MessageLevel messageLevel, String message) at Inedo.ProGet.Service.DropPathMonitorExecuter.Execute() at Inedo.TimedExecuterBase.ExecuteMethodHost(Object state) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.TimerQueueTimer.CallCallback() at System.Threading.TimerQueueTimer.Fire() at System.Threading.TimerQueue.FireNextTimers()
This happens during a migration from the 'old' feed setup to the new structure that has been introduced in the update to 3.3.3.
Im using the bulk migration of packages from the old feeds to the new one, by dumping to a monitored folder.- First major issue is that there is no way to reference the error in the message to the offending package in the database. Why not log unique information that allows for finding the entry in the packages table, could be Package_Id and Published_Date. 547
16
0` does not really help much. - Can i do something manually?. I guess an entry is missing in the DB because of FK error, but right now i cannot fix it manually since a lot of relevant information is missing in the error message.
Best regards
ThomasProduct: ProGet
Version: 3.3.3
- First major issue is that there is no way to reference the error in the message to the offending package in the database. Why not log unique information that allows for finding the entry in the packages table, could be Package_Id and Published_Date. 547
-
I have now found the package that is creating the issue in Proget.
There is no source nor PDB found in the nupkg package that is being imported.I properly need to define the feedsetup:
- It is of course Active
- Symbols and source server is activated
- Automatic strip pdb on download is active
I have tried variations of these settings as defined below.
case 1:- Symbols and source server is activated
- Automatic strip pdb on download is deactivated
case 2:
- Symbols and source server is deactivated
- Automatic strip pdb on download is deactivated
I have tried to following in the databse:
Delete all instances of the package in the [ProGet].[dbo].[Packages] table where the package was referencing the feeds i was trying to update.
I have removed any Symbol references for the package that was also referencing the feeds in question. Table of concern: [ProGet].[dbo].[Symbols]None of these actions has had any effect
This is turning into a quite big issue where a package can actually not be imported in a feed.
It is also concerning that the packages are actually present in the old feeds (the older standard) where they have been imported fine, with symbols.
-
What is the version of the package that is causing the problem? This could happen if it's not a valid semantic version - in particular one with leading zeroes (such as 1.02.10 instead of 1.2.10). Numbers like this are supposed to be parsed and normalized before being used in the db, but it's possible that's not happening here.
If this is the problem, we can send you a SQL script that will patch the Packages_CreateOrUpdatePackage stored procedure.
-
What is the version of the package that is causing the problem? This could happen if it's not a valid semantic version - in particular one with leading zeroes (such as 1.02.10 instead of 1.2.10). Numbers like this are supposed to be parsed and normalized before being used in the db, but it's possible that's not happening here.
The version is of the format: yyyy.mm.dd.bb
In the exact case: 2014.11.05.02
As stated earlier this exact package has been imported into the old feeds without any issues.
-
And as extra info.
Proget is updated to 3.3.4 with same issues.
-
I've emailed a SQL script you can try to the notification address you provided to this forum. Let me know if it helps.
-
I've emailed a SQL script you can try to the notification address you provided to this forum. Let me know if it helps.
I have responded via email, but for future reference i am also going to respond here.
Script ran, modified 2 rows, and i was now able to import the package using the Bulk import folder option.
However the package is not showing up in a correct manner in the Proget view.
as can be seen in this image on dropbox:
-
However the package is not showing up in a correct manner in the Proget view. as can be seen in this image on dropbox:
Dean was able to send me yet another SQL script that resolved this issue.
Dean/Proget team.
Thanks for your fast an consistent help in this matter.I regard this issue as resolved, but to fix it some manual database steps are required, and they are not really nice to do on production servers.
I guess a hotfix might be in store for this.Kind regards
Thomas
-
Thanks to Thomas for his help in figuring this out. We will be including a fix for this issue in v3.3.5.
If anyone else encounters this issue and we have not released 3.3.5 yet, email us at support -at- inedo.com and we will send you the patched SQL scripts.
Note that this issue only affects versions 3.3.0-3.3.4.
-
Upgraded to 3.3.3 to 3.3.11 and noticed that now ProGet just removes leading zeros from the package name. So 1.2.0102.175 becomes 1.2.102.175. Is it possible to keep the name as is?
-
It does remove those zeros for internal storage, but it should return the original version in queries and as part of the file name when you download the package.
-
Hi Dean,
That did not work right after the upgrade for some reason, ProGet was creating packages without leading zeroes and our deployment step was failing as it wasn’t getting the right package. Now after few days it seems to work, strange. Well, all good while it works.Minor thing that I noticed though, when you select package in ProGet UI, it still shows version number without leading zero. That’s in the section where it provides command examples:
YourPackage 1.2.0105.105To install YourPackage from the command line, run the following command:
nuget install YourPackage -Version 1.2.105.105 -Source http://YourServer:10030/nugetNot a biggy, but might get some people confused.
-
It could be that the versions were fixed up when a package cleanup ran - happens every day by default, but may not have been immediately after the upgrade.
Thanks for letting us know about the zeros missing from that page; we'll add an issue for this to get fixed in the next release.