problème affichage attachement après migration 8.2z vers 12

38 views
Skip to first unread message

medovitch kaspy

unread,
Sep 8, 2025, 5:25:50 AM (yesterday) Sep 8
to iDempiere
Hello everyone,
On Windows, using pgsql15.3, attachments are stored in the database. After migrating from version 8.2z to version 12, we noticed that all the attached files in version 8.2z no longer appear in version 12. If we run a query for (ad_table_id, record_id), the record is still present. If we try to add a new attachment, we get the message that the keys (ad_table_id, record_id) are violated. Of course, the buttons remain disabled. At the business level, this is really annoying now. Even for jrxml report files, it's the same thing. The file names are configured as follows: attachment:<filename>, and we were forced to put them back with the file names on disk in the /reports folder. We had already performed a migration to version 11 before, but because of this problem, we reverted to version 8.2z.
Is this a mistake on our part please. Thank you for your attention.
Could you please direct us?

Andres Lopez Andrade

unread,
10:28 AM (6 hours ago) 10:28 AM
to iDempiere
Hi

To help you better, it would be best if you complete the message. You've given us an idea of your problem, but it would be much better if you could attach the migration log files. It's possible that a script needs to be run or that you received an error when updating a table. It's also a good idea to attach the log when you want to attach another file—basically, anything that helps us help you.


medovitch kaspy

unread,
1:55 PM (2 hours ago) 1:55 PM
to idem...@googlegroups.com
Hi,

Thank you for your reply. 
Sorry for the lack of clarity. After some research, I found that the attachment.record_uu field, newly added in the latest versions, contains a NULL value, which makes the attachments invisible. The migration seems to have been successful; all scripts were applied, and version 12 works perfectly on Windows Server (especially in terms of response time, compared to version 8.2, with 4 remote sites and a central server). I tested updating a row in the ad_attachment table with the record_uu field, using the UUID from the corresponding table, and the attachment then appeared. I am preparing a script to update ad_attachment.record_uu all rows. I don't understand why record_uuid is NULL. I also noticed that some user tables do not have a UUID column. Therefore, we will perform an audit and make modifications to comply with Idempiere requirements. (I inherited this situation.)  questions : Does Idempiere offer a solution for:
1. Automatically updating the ad_attachment.record_uu data?
2. Checking for and creating missing <table_name>_uu columns in user tables?
3. Creating a unique UUID index ?
The second step will be to configure attachment storage on disk. Currently, our database is several GB in size, and attachments are stored on disk.

What do you recommend: storage on disk or in the database ?

Thank you

--
You received this message because you are subscribed to the Google Groups "iDempiere" group.
To unsubscribe from this group and stop receiving emails from it, send an email to idempiere+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/idempiere/bf1a7618-9270-4e56-9587-4262ffd1e9bfn%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages