Linked table data not refreshing without a Compact & Repair on FE MDB

[Qubit]

Something funky is happening: Access 2K MDB split with BE on Samba share, User.MDB FE on three Win7Pro machines.

-MDB was split some time ago to User frontend and Data BE. The BE MDB data resides on a CentOS 5 Linux box, with Samba 3.0.33.
-all users have MDB storage on Samba box mapped to drive R:\
-has worked perfectly until a week or two ago...

Usually, when user 1 deletes a record while user 2 is viewing the table data, the offending record shows as #deleted for user 2. Closing and re-opening the table by user 2 does not show the deleted record. As it should be.

Recently, the #deleted records only go away when you do a Compact & Repair.
Similarly, when user 1 adds a record, user 2 cannot see it no matter what unless Compact & Repair.

I'm getting 'Record is deleted' when any code runs that retrieves records from a table where one of the records was deleted since the last time it was looked at.
I cranked the ODBC refresh interval down to 5 secs...no good - and the locking strategy has not changed.

The only two changes I can think of was regarding the Samba config where the Kyocera printer that we have would not allow us to scan to a folder on the CentOS box, so I put security= SHARE into the service defs like this:

[backup]
path = /home/xxxxx/backup
writeable = yes
; browseable = no


guest ok = yes
security = SHARE
Which resolved that issue, but gave me warnings from TESTPARM.

We also have had two xp machines replaced with win7pro.
I have a drive letter mapped to each of my (2) users' User.MDB folder, so to re-distribute all I have to do is xcopy the User.MDB to their drive letter.
However, I notice that the 'other' new win7pro machine does not automatically re-connect the mapped drive. I can't deliver the new User app without first opening the drive in an explorer and giving it the credentials.
The other machines do not have this problem.

I have checked the BE indices and all seems normal - did a compact/repair on it as well.

Q: would some differing security settings between the win7pro machines account for the not-reconnecting thingy and could the same thing do funny things to the BE MDB?

Q: could the change in the Samba settings cause funny problems?

It's getting frustrating chasing a bug that seemed to have crawled in under the door all by itself.

Thanking anyone in advance for any good ideas...
/Q

[ranman256]

Instead of compact/repair, did you try refresh the relink to the table?

[Qubit]

Instead of compact/repair, did you try refresh the relink to the table?

Sure did. I do have some temp tables that get toasted by various routines and are user-centric and they were originally in the User.mdb file.
Since that file is now about 250 MB, I decided to relocate them to a TempTables.mdb, which lies beside the User.mdb.
I would then link to all tables in both Data.mdb and TempTables.mdb.

Since this weirdness started, I have brought them back in to the User.mdb - no effect.

Once in a while I delete the linked tables, then re-link to the back end, especially if a table structure changes.
To use a new table, I usually create it in the User.mdb, test it, export it to the Data.mdb, rename the table in User.mdb and then link to the new table in the Data.mdb and re-issue User.mdb.

This critter has been alive and well for ten years now, and the ONLY thing that has given me grief in that time was Service Pack 3 when we were XP. Other than that it's all been good.
I also backup the Data.mdb file regularly and compact/repair it once a week (to take care of the old memo-field remnants etc).
.Q