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

[medovitch kaspy]

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]

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]

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.

[Carlos Antonio Ruiz Gomez]

Hi,

> questions : Does Idempiere offer a solution for:

> 1. Automatically updating the ad_attachment.record_uu data?

The migration script 202305291332_IDEMPIERE-5567.sql must have taken care of that, maybe it failed in your migration, or maybe it was interrupted.

I think you can simply try to run the script again.

You can find the update of ad_attachment_uu in the line 240:

https://github.com/idempiere/idempiere/blob/e4b5dde197cef3bb542b782a5d286a3663781eb7/migration/iD11/postgresql/202305291332_IDEMPIERE-5567.sql#L240

> 2. Checking for and creating missing <table_name>_uu columns in user tables?

The process UUID Generator

I would recommend you to run it first in a test database and analyze the results before applying it in production.

> 3. Creating a unique UUID index ?

The process Create/Complete Table do this automatically for you, but for old tables I think you need to create the index manually

> 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 ?

It depends on your needs and usage of the attachments.

The process Migrate Storage Provider can help you to try (as usual, please check first in a test database).

Regards,

Carlos Ruiz

[Aziz Kayoueche]

Bonjour 
Je veux migrer Idempiere de 8.2 vers le 12 et j'ai des fichiers attachés, comment faire?

[Andres Lopez Andrade]

That's great that you found the error! Here's a response to your questions:

1. UUID Generation: In the Tenant system, there's a process called UUID Generator. You can use it to fill empty fields by simply typing the name of the table in the parameters. If you leave the parameter blank, it will generate UUIDs for all tables.

2. Working Without a UUID Field: I don't think there's a process for that, but you can work with some tables even if they don't have the _UU field.

3. UUID Uniqueness: Yes, the UUID field must be unique.

Regarding the attachments, storing them in the database or on a disk depends on the kind of access you need and the type of disk you plan to use. In my case, because of the sheer volume of information we handle, we prefer to store images on disks.

Regards,

Andres

You received this message because you are subscribed to a topic in the Google Groups "iDempiere" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/idempiere/pFiS6MUQMmw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to idempiere+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/idempiere/CACamO0JvuEEGqMmiyCW%3Das47Sbw0pQssp3Rs4JhUuGM8XpfHiA%40mail.gmail.com.