Service Desk Practitioners Forum

Exist other table where Attachment Information is SAVE?

Erika Fabiola G
Valued Contributor.

Exist other table where Attachment Information is SAVE?


I hope this time somebody can reply my message because i posted two related items about this topic but nobody answer me.

I need your support! The system is Service Desk 4.5 SP15 on Windows Sever 2003 R3. Actually the attachment section is working however we wanted to introcuce a FTP quota in order to control our disk space.

The situation is the follow;
- a record is created (Service Call, Incident, Problem, etc)
- several files are added by attachment process (the total size to save is bigger than quota)
- Saving record and immediatly appears a error message FTP 550 error : 281548308283540

I have checked REP_ATTACHMENTS using the ahs_att_oid field but the code_number that message show didn't exist on it ... so as i'm new in Service Desk enviroment i request your support to identify which other table maybe is capturing that number_code (ahs_att_oid)?

Any time when i pretend to save again the record, i received the same error but with diferent number_code or oid.

Thanks in advance!
Erika Gris
Acclaimed Contributor.

Re: Exist other table where Attachment Information is SAVE?

Hi Erika,

If you run a select against REP_ATTACHMENTS table, you should see the columns:

AHS_ENT_OID=represents the entity type (e.g. 724041768 means CHANGE).

AHS_ATT_OID=represents the entity item, which references the OID column of the corresponding entity table (e.g. ITSM_CHANGES).

So, based on that, I believe that the SQL query to find the specific record would be like this:


Hope this helps...

Randall Barrantes
SW Support Delivery Manager
Erika Fabiola G
Valued Contributor.

Re: Exist other table where Attachment Information is SAVE?

Thank you! I already did that but i have detected the follow:

my repository (FTP) has a quota so when i save the record with attachment_file (bigger than quota) is save incomplete appearing an error with the ash_oid assigned as reference ... the worst part is even we remove the attach_file inside of the record, apply the save & close button unfortunly the repository (ftp folder) has already the attach_file ... it's alive :(
but the relation or record doesn't exist on rep_attachments, because it is on folder if i pretend introduce more attach_files the error come on.

How we can stop the file will be save if there's no enough space?

I accept suggestion, recommendation , best practices, etc ...

Thank in advance!
Erika Gris
Monterrey, Mexico
Outstanding Contributor.

Re: Exist other table where Attachment Information is SAVE?

Just buy some more disk. I had a ftp with 150GIG. (no quota). 4.5 has a one year life left. You can monitor disk space usage on the FTP slice. If it gets to 80% then think about increasing. Disk is cheap. Try and make an FTP slice which will give you 12-18 months of space. And Use the time you would have spent on setting up quota to learn SM7 or other.
Erika Fabiola G
Valued Contributor.

Re: Exist other table where Attachment Information is SAVE?

Thanks! but you know if you give more space to users it never will be enough!!!,

Basically my problem is with the application when use the "Save & Close" option to close the record, the attachment files are saving but unfortunly if those have a size bigger than quota, an error message appears (normal) but those are alive under ftp area but no found on rep_attachments table.

As example, ftp quota equals 4MB so if the file to add has 4.85MB the application just save 4MB (so is not saving complete :( )

I assume the HP Service Desk works but pretending to apply quota the internal program can't understand the error so that's why save a partial file and the close process is NOT COmplete (there's no record or relation on attachment table).

I'll re-open a previous case related FTP 550 error with HP however somebody knows if exist a temporal table where detect attachments relation in order to verify size or create a rule as system command ?

Thanks in advance!
Erika Gris
Monterrey, Mexico.