Attachment field not properly deleted if parent row is deleted (1 Viewer)

Hello all,
I tried searching for this, but couldn't find any results. I've got the following problem with the newly introduced attachment field: If a recordset containing an attachment field is deleted it appears that the underlying subrecordset containing the files isn't. Now, if the database is compacted and the auto value primary key is reused (of deleted rows) the files suddenly reappear. This behaviours is replicable and leads to severe problems within my application as suddenly the attachment field contains files that shouldn't be there. Additionally, the database is growing excessively as filedata is never removed if the row is deleted. Furthermore, the database cannot be compressed otherwise the above mentioned problem occurs which additionally expands the database Any ideas? Is that a confirmed bug already and any patch available?
As an additional info that may help bug tracing: the db containing the table with the attachment field is a linked db. I didn't try to replicate that behaviour with a table within the same db.

Thanks,
Mike

From where do you link your tables?
If it's from one other Access database you need to enforce relational integrity and enable cascading delete on the relation between the two tables in that database.
If it's from two different databases you need to write some code to delete the attachment field records.

Hello Peter,
Thank you for your answer. The application is split into a frontend database where all the forms, reports, queries,... are stored and a pure data storage db where among others the problematic table is stored. It is a single table containing an attachment field. I guess it's not a relationship related issue. Simply because there is no relationship between this table and others. The simple problem is that the files in the attachment field are not deleted from the db if the entire row is deleted. What I mean is that obviously they don't show up anymore once the row is deleted. But, first of all the database is constantly growing although old files are constantly deleted (compression doesn't help). Second, if the db is compressed and auto value primary keys are reused, old files suddenly reappear. E.g. a row with the primary key value 12, which is the current highest value, containing files in the attachment field is deleted. Next auto value would be 13. But, if the database is compressed access also resets auto values to their lowest possible value. Now, the next newly created row also gets primary key value 13 and suddenly, although it would be an entirely new record, the old files reappear in the attachment value. This can be replicated for all primary keys ever used.
I guess, access internally stores the attachment field subrecordset in a hidden sytem table which doesn't get updated properly if the field in the primary table is deleted and therefore the link reappears if a related primary key is recreated. I consider this as a bug not a feature. The problem with purging the attachment field prior to deleting the record is that DAO code is not very reliable with respect to the attachment field. recordset.eof, .bof and .recordcount values are never properly set so navigating through the attachment subrecordset is a tough thing to do by code. I only managed to do this by dirty error management, but that's not clean reliable code.
regards,
Mike