Skip to main content

We have an issue where a user is trying to open a file attached to a contract, and get the following error:

In the event log I see that the file name looks a bit funky (the name is HIN76766_870844.pdf)

The file is in the AsteaShare-folder:

I only find this reference in the database (and not where the link is stored). ap_attachement_xref only has 98 lines 

 

Hi Bjørn,

Does this happen only for this attachment or all attachments? 

As you already determined, the attachment information is stored in the ap_attachments table.  It appears that it is taking the ap_file_name and adding the ap_attachment_id AGAIN as a composite name when it is requesting the file.  As the filename is already containing the ID in the database, this would duplicate the ap_attachment_id in the request.

Can you please send me that file so I can add it our environment to run some tests here?

I am checking here and do see something that might point to this.


Thanks for the reply, Phil

I was strongly urged to “fix this ASAP”, as Customer Service needed the file. So I copied it to my PC and uploaded it to the contract again. And now it works.

The naming seems consistent with other documents.

I will send yoiu the file, though

New upload (I ah already deleted the old attachment link in Astea)

 


Hi Bjørn,

When I add a new attachment to the same contract here, it does not contain the ap_attachment_id as part of the filename.

select ap_attachment_id, ap_file_name, p_key, surrogate_ap_attachment_id
from ap_attachments
where ap_table_name = 'cconth'
--and ap_attachment_id = 870844
and ap_table_key = 'HIN76766'

 

 

I suggest removing the _870844 from the string in the ap_file_name column.

Your comment above came in while I was editing this one.  So, the new attachment still has that string for the ID added in the column while my test did not but I did not use the same file which I don’t think should have influenced the test.

The reason your new upload worked is now officially the _870844 is part of the filename itself.  You probably will have this problem with other attachments as v15.2 HF4 does not add the ap_attachment_id as a suffix in the file name within the column.

 


That is interesting, because when I uploaded the file again it added the NEW ap_attachement_id as part of the file name as well. I excpect this may be because HIN76766 is already used on other attachements?

Removed the _870844 and added again:

And this in the DB:

 


I see that the id is added to all files - also back in v 12.5:

 


Hi Bjørn,

This is working as designed, whatever the filename is at the time of the upload, the filename in the database is not changed (see ID 895850) however the actual filename saved to the server is modified to contain the new ap_attachment_id as part of the file name.

 

If you had saved it with the earlier version of the code, the filenames in the database would have been:

ID              Filename

895812    HIN76766_870844_895812.pdf

895850    HIN76766 _895850.pdf

 


Hi Phil,

I reported this issue under US0061101. 

This is the script I use to find the attachments which have the issue:

SELECT

       p_key,

       ap_description,

       ap_file_name,

       ap_table_name,

       ap_table_key,

       ap_creation_date,

       ap_user_login,

       lang_id

FROM ap_attachments WITH(NOLOCK)

WHERE ap_file_name like '%' + p_key + '%.%'

ORDER BY ap_creation_date