I recently ran into an issue where a client was trying to restore a file system copy of the VFS into the database VFS after completing a development project. This file system VFS had been shared by several developers using a Git repository. When restoring to the database VFS, the restore process would reach near the end and then would throw an error “String or binary data would be truncated’.
I was not sure why this would be happening since the database VFS and file system VFS were both running against the same database stucture. I ended up running the SalesLogix profiler against the application architect to determine what process was throwing the mentioned error.
I was able to find the particular SQL statement that was executing when the error occurred. By examining the values in the SQL statement and comparing them to the structure of the VIRTUALFILESYSTEM table in SalesLogix I was able to find the problem. It turns out the problem was that the file system VFS had spawned some extra files, probably as a result of using a file merge utility to handle differences in the Git Repository. These files had a file extension containing the normal extension, plus a GUID value like “resx~0bebfa6b0e6cb7370d767081291c8e71a7756f36”. The SalesLogix VIRTUALFILESYSTEM table has a column called ITEMEXTENSION which stores the file extension of each file in the VFS. This column is defined as only 12 characters.
Looking at the SQL statement again in the profiler I was able to determine the location of the file in the file system VFS by looking at the value being inserted into the ITEMPATH column. I then located that directory in the file system VFS and found the files. There were actually several with the problem:
Doing a quick examination of these files revealed an identical file with a correct file extension. The solution, in my case was simply to remove the extra files and I was then able to import the file system VFS into the database VFS without issues.