NBEA Intern Posted January 27, 2011 Share Posted January 27, 2011 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 Link to comment Share on other sites More sharing options...
bcooney Posted January 28, 2011 Share Posted January 28, 2011 Still having problems? What is the relationship between the "Main" table and the container table? Hopefully, unique, indexed key fields. Link to comment Share on other sites More sharing options...
NBEA Intern Posted February 1, 2011 Author Share Posted February 1, 2011 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 Link to comment Share on other sites More sharing options...
NBEA Intern Posted February 1, 2011 Author Share Posted February 1, 2011 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 Link to comment Share on other sites More sharing options...
Vaughan Posted February 1, 2011 Share Posted February 1, 2011 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. Link to comment Share on other sites More sharing options...
NBEA Intern Posted February 3, 2011 Author Share Posted February 3, 2011 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? Link to comment Share on other sites More sharing options...
Recommended Posts
This topic is 4823 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now