Hi, I have a unique problem that I hope someone could help me figure out:

In our database setup, we have a containers database separate from our main database. We have successfully linked the 2 and can store records to the Containers database from the main database. Just up until a couple weeks ago, everything was working just fine. However, now when trying to pull all containers related to a certain entity, it fails to search the Container database. When I saw this, I opened the containers database and manually tried searching for data that I knew was in there, though it still says "No records found".

I have indexed my primary keys and can see the data, though it just doesn't seem to find it. This same issue occurs on all tables in this database. I just don't know if there is a setting that might make all the tables "unsearchable" that could have possibly been set?

Any help would be greatly appreciated.

- Dan

Still having problems? What is the relationship between the "Main" table and the container table? Hopefully, unique, indexed key fields.

We link our tables by our Entity pk (main table, unique and indexed) and set that as the Container fk. Though, like I said before, I can't even perform a find on the Container database itself, let alone searching through the link. I'm just wondering if there's a setting to make it stop searching because it was working fine until a couple of weeks ago.

Thanks again,

- Dan

I fixed the issue. Apparently all I needed to do was recover the database. I used this link if anyone needs help with a similar issue:

Recover FileMaker

Did you read the article right through to the end?

It is important to understand that the Recover command is a temporary fix to help recover data. If is very important that the data in the recovered file be migrated to a clean copy of the StudioSchool Pro database files as soon as possible. The continued use of Recovered files may lead to further problems.

Recovered files are not suitable for production. The recovery process is designed to get the data out and it will bulldoze everything else in the file to do so. It's possible that bits of layout or scripts could be missing.

That article is not best practice. The first step would be to use the Save a Compacted Copy command and test whether the problem is resolved. The compaction process repairs a lot of simple problems and the resulting file is good to go back into production as-is. Only if the compacted copy is bad would the file be recovered, and then the data would be imported into a known-good clone so the recovered file is not used.

How would I go about Saving a Compacted Copy and testing if it's ok? Would I perform this test on the recovered database or the original (damaged) one?