While installing the package we are facing String truncated error

Hello,

This message usually appears when you try to import data of (N+1) length in a field that supports N length. For example you have a field in a target instance that supports 256 symbols and contains 255 symbols and you tr to install a package which will change the supported data type to 128 symbols that will lead to data truncating. You need to check supported data type (especially for string fields) in a package and make sure that it is not less than data type supported by a target instance field.

Best regards,

Oscar  

Hello,

We tracked the package installation failure using SQL Profiler and we found the fails with the below query 

INSERT INTO [dbo].[SysInstalledApp]([Id], [CreatedOn], [CreatedById], [ModifiedOn], [ModifiedById], [Name], [Code], [Maintainer], [InstallDate], [MarketplaceLink], [HelpLink], [FileLink], [SupportEmail], [OrderLink], [SysInstalledAppStatusId])

VALUES(@P1, @P2, @P3, @P4, @P5, @P6, @P7, @P8, @P9, @P10, @P11, @P12, @P13, @P14, @P15)',N'@P1 uniqueidentifier,@P2 datetime2(7),@P3 uniqueidentifier,@P4 datetime2(7),@P5 uniqueidentifier,@P6 nvarchar(62),@P7 nvarchar(62),@P8 nvarchar(4000),@P9 date,@P10 nvarchar(4000),@P11 nvarchar(4000),@P12 nvarchar(4000),@P13 nvarchar(4000),@P14 nvarchar(4000),@P15 uniqueidentifier',@P1='A1D1CB31-65E9-4F87-996F-9AD0D9A59F46',@P2='2019-02-14 15:18:21.5818375',@P3='410006E1-CA4E-4502-A9EC-E54D922D2C00',@P4='2019-02-14 15:18:21.5818375',@P5='410006E1-CA4E-4502-A9EC-E54D922D2C00',@P6=N'ABBTF_AccountsContactsLeadsEventsDataBinding_19.01.30_15.47.16',@P7=N'ABBTF_AccountsContactsLeadsEventsDataBinding_19.01.30_15.47.16',@P8=N'',@P9='2019-02-14',@P10=N'',@P11=N'',@P12=N'',@P13=N'',@P14=N'',@P15='EA07D324-76E7-40F9-9738-8C5FD21F2BAF'

We found that The problem is in the "Code" field of the table "SysInstalledApp". It takes a max of 50 characters. That is why, inserts into this table for packages with names greater than 50 characters fail. The package that we tried to import is ABBTF_AccountsContactsLeadsEventsDataBinding_19.01.30_15.47.16. the timestamp gets appended at the end of the package name. Is there a way to mitigate the same?

We also have few questions on the same:

1) We have a few packages installed in the client's dev cloud environment. Is this the last step as part of the installation? Can we assume no impact to functionality because of this issue?

2) We see that the timestamp is automatically added to the package when we export it into an archive(for example, ABBTF_AccountsContactsLeadsEventsDataBinding_19.01.30_15.47.16). It adds an extra 18 characters to the name of the package? Would there be an impact on the importing process if we manually remove the timestamp from the name and import the package? We feel this could help resolve the issue, but we weren't sure of the impact. Does BPM'Online depend on the timestamp for some internal processing logic?

3) Is there a way of generating the archive for a package in the expected format directly from SVN instead of using the "Export packages to archive" option in BPM'Online?

4) As a resolution for this problem just for this particular implementation,can we include an alter table script to increase the length of the "Code" column of the "SysInstalledApp" table?   Would this be safe?

Dear Sri,

Yes the timestamp is automatically added to the package which is exported from bpm'online and it is done so if you apply any changes after exporting you could simply find a package you need. You can remove this timestamp in a resulted file and it won't change anything.

As per your questions:

1) If you uploaded a package to the new environment and there are no errors during compilation - then the process is finished successfully.

2) You can remove this timestamp from the file and import it into the system using "Installed applications" section http://prntscr.com/monwvn

3) When generating a file from SVN it should also insert a timestamp into the file and you can simply remove it in resulted fire by renaming it.

4) Well you can try doing it, but it is not recommended since timestamp is used to differ one package from another and as a result it can lead to confussions when choosing a correct package.

Best regards,

Oscar