cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Inventory File moving to Badlogs->Failure folder

Hi All,

Has anybody has come across this error while importing ndi file, this is happening for a set of device irrespective of OS,  while rest works fine. 

" System.InvalidOperationException: The given value of type Int64 from the data source cannot be converted to type int of the specified target column. ---> System.OverflowException: Failed to convert parameter value from a Int64 to a Int32. ---> System.OverflowException: Value was either too large or too small for an Int32 "

Attached full error message in the attachement.

But when same set of ndi files are imported into our test envirnoment which is almost identical, it goes fine with out any error.

We are on 2019 R2 and 2014 SQL server

(2) Solutions

The only fix I'm aware of for IOJ-2091541 is in the 2020 R1 or later releases sorry - I am not sure that any analysis has been done previously to consider what would be involved in hotfixing or working around this problem in earlier releases.

If you are not planning an upgrade to a current release at this time, you would need to work with Flexera Support to confirm whether this is indeed the issue affecting your environment and discuss options.

(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)

View solution in original post

Thanks @Alpesh, an custom script from Engineering/support helped us reseed and fix this issue

View solution in original post

(9) Replies
ChrisG
By Community Manager Community Manager
Community Manager

This error looks like it may be related to the following known issue that is shown as resolved in the 2020 R1 release:

MASTER ISSUE NUMBER COMPONENT/S SUMMARY
IOJ-2091541 Database, Inventory, Uploaded file importers

Inventory NDI files fail to import when the SoftwareFile_MT.SoftwareFileID database identity column exceeds 2,147,483,647

 

Are you using a version of FlexNet Manager Suite from 2019 or earlier? And does the SoftwareFile_MT.SoftwareFileID column in your inventory database contain values larger than 2,147,483,647?

(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)

Hi @ChrisG

We are using 2019 R2

Can help to direct us to the hotfix for 2019 R2 for this or share it please

The only fix I'm aware of for IOJ-2091541 is in the 2020 R1 or later releases sorry - I am not sure that any analysis has been done previously to consider what would be involved in hotfixing or working around this problem in earlier releases.

If you are not planning an upgrade to a current release at this time, you would need to work with Flexera Support to confirm whether this is indeed the issue affecting your environment and discuss options.

(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)
Hi @ChrisG,

This is not the issue, just verified we haven't hit 2,147,483,647. we haven't even reach half way mark. so does not seem to be this issue

Also this seem to be coming up predominantly in for all of the failed to import  files, 

" System.InvalidOperationException: The given value of type Int64 from the data source cannot be converted to type int of the specified target column.

---> System.OverflowException: Failed to convert parameter value from a Int64 to a Int32.

---> System.OverflowException: Value was either too large or too small for an Int32 "

Hi @nagaeendra: Based on your comment that the max SoftwareFileID is less than half the max value of the Identity column, you should try to reseed the Identity value for the SoftwareFile table. I see you have a case with Support on this topic and they will give you the SQL to reseed the SoftwareFile table.

Hi @Alpesh,
Yes, we now tried that too, but it did not work for us, we see same error again after reseed.
Thanks @Alpesh, an custom script from Engineering/support helped us reseed and fix this issue