Hi all. I've been able to get my FM solution up and running. It's not the best, but it's functional and I've come to rely heavily on it. I've got Backup backing up my database every night to keep data catastrophes from occurring. Now I've got some strange things going on with my database, though.

One of my table has lost all it's fields! The records are still there, as shown in the "define database -> tables" tab, but the fields are all gone. I'm not sure what the best way to deal with this is. I've got "Special Edition: Using FM Pro 7" and it only suggests doing a "File: Recover" to deal with database problems. Any other things I can try?

Also, 2 of my layout screens have quit working. They show up in the layout list, but when I select them, the name blanks out I can't do anything at all. I can't even delete the layouts.

It seems like I've got some pretty major problems with my database. How can I salvage my stuff and keep this from happening again? I've got several older copies of the database that I can roll back to, but I'm worried that this will happen again.

edit: I forgot to mention that I'm running v1. I'm TRYING to update to v3, but the damned updater is "searching" for the application on EVERY mounted disk. What's that about?

Hi all. I've been able to get my FM solution up and running. It's not the best, but it's functional and I've come to rely heavily on it. I've got Backup backing up my database every night to keep data catastrophes from occurring. Now I've got some strange things going on with my database, though.

One of my table has lost all it's fields! The records are still there, as shown in the "define database -> tables" tab, but the fields are all gone. I'm not sure what the best way to deal with this is. I've got "Special Edition: Using FM Pro 7" and it only suggests doing a "File: Recover" to deal with database problems. Any other things I can try?

Also, 2 of my layout screens have quit working. They show up in the layout list, but when I select them, the name blanks out I can't do anything at all. I can't even delete the layouts.

It seems like I've got some pretty major problems with my database. How can I salvage my stuff and keep this from happening again? I've got several older copies of the database that I can roll back to, but I'm worried that this will happen again.

edit: I forgot to mention that I'm running v1. I'm TRYING to update to v3, but the damned updater is "searching" for the application on EVERY mounted disk. What's that about?

Hi all. I've been able to get my FM solution up and running. It's not the best, but it's functional and I've come to rely heavily on it. I've got Backup backing up my database every night to keep data catastrophes from occurring. Now I've got some strange things going on with my database, though.

One of my table has lost all it's fields! The records are still there, as shown in the "define database -> tables" tab, but the fields are all gone. I'm not sure what the best way to deal with this is. I've got "Special Edition: Using FM Pro 7" and it only suggests doing a "File: Recover" to deal with database problems. Any other things I can try?

Also, 2 of my layout screens have quit working. They show up in the layout list, but when I select them, the name blanks out I can't do anything at all. I can't even delete the layouts.

It seems like I've got some pretty major problems with my database. How can I salvage my stuff and keep this from happening again? I've got several older copies of the database that I can roll back to, but I'm worried that this will happen again.

edit: I forgot to mention that I'm running v1. I'm TRYING to update to v3, but the damned updater is "searching" for the application on EVERY mounted disk. What's that about?

How is the file being shared -- on a network drive or with FM Server?

Start searching for backup copies of the databases now -- as far back as you can. Use the Recover command to get the data out of the most recent copy, then import the data into a known-good clone of the file (this is what the backups are for). It's important that the copy you import into is known to have no corruption.

If there is any doubt that the copy may not be perfectly clean (if the files have been shared on a network volume the backups probably all have corruption going back months or years) then rebuild the file structure from scratch.

How is the file being shared -- on a network drive or with FM Server?

Start searching for backup copies of the databases now -- as far back as you can. Use the Recover command to get the data out of the most recent copy, then import the data into a known-good clone of the file (this is what the backups are for). It's important that the copy you import into is known to have no corruption.

If there is any doubt that the copy may not be perfectly clean (if the files have been shared on a network volume the backups probably all have corruption going back months or years) then rebuild the file structure from scratch.

How is the file being shared -- on a network drive or with FM Server?

Start searching for backup copies of the databases now -- as far back as you can. Use the Recover command to get the data out of the most recent copy, then import the data into a known-good clone of the file (this is what the backups are for). It's important that the copy you import into is known to have no corruption.

If there is any doubt that the copy may not be perfectly clean (if the files have been shared on a network volume the backups probably all have corruption going back months or years) then rebuild the file structure from scratch.

I'm using "filemaker network" to serve the file. I've got a relatively recent I think uncorrupted copy of the db. I'm doing the importing now. How do I ensure that the clone I'm working on is ok? It doesn't exhibit the strange behavior of the other, so can I assume that the structure is sound?

So far, you've saved me a TON of time. I really appreciate it. Now, how can I prevent this from happening again? Thanks again!

I'm using "filemaker network" to serve the file. I've got a relatively recent I think uncorrupted copy of the db. I'm doing the importing now. How do I ensure that the clone I'm working on is ok? It doesn't exhibit the strange behavior of the other, so can I assume that the structure is sound?

So far, you've saved me a TON of time. I really appreciate it. Now, how can I prevent this from happening again? Thanks again!

I'm using "filemaker network" to serve the file. I've got a relatively recent I think uncorrupted copy of the db. I'm doing the importing now. How do I ensure that the clone I'm working on is ok? It doesn't exhibit the strange behavior of the other, so can I assume that the structure is sound?

So far, you've saved me a TON of time. I really appreciate it. Now, how can I prevent this from happening again? Thanks again!

"How do I ensure that the clone I'm working on is ok?"

That, they say, is the trick.

Well organised developers ensure the files never crash during development and backup accordingly. Once the solution is done, clone copies of the files are burned to CD and kept safe: these are the "known-good copies". Any changes made to the working system have to be also made to the cloned copies, or if the working copies are still known to be good new clones are made from these.

It's a lot of work and it needs good organisation, but you can see their importance.

"How do I ensure that the clone I'm working on is ok?"

That, they say, is the trick.

Well organised developers ensure the files never crash during development and backup accordingly. Once the solution is done, clone copies of the files are burned to CD and kept safe: these are the "known-good copies". Any changes made to the working system have to be also made to the cloned copies, or if the working copies are still known to be good new clones are made from these.

It's a lot of work and it needs good organisation, but you can see their importance.

"How do I ensure that the clone I'm working on is ok?"

That, they say, is the trick.

Well organised developers ensure the files never crash during development and backup accordingly. Once the solution is done, clone copies of the files are burned to CD and kept safe: these are the "known-good copies". Any changes made to the working system have to be also made to the cloned copies, or if the working copies are still known to be good new clones are made from these.

It's a lot of work and it needs good organisation, but you can see their importance.

Absolutely. The more I work with FMP, the more I realize that it's a very rich environment. I'd like to learn more than my books can teach me.... So far, I've convinced the people I work with that it's been a very good investment. I'm trying to get them to pony up the dough for a copy of FM Server and a few more copies of FMP because I think it'll streamline our tracking/data collection greatly. I just hope we don't have many more near disasters like this one. I'm still curious about what could have caused the corruption and what I can do to prevent it. I was looking at a very long night getting it all working again. Thank goodness you posted when you did.

Absolutely. The more I work with FMP, the more I realize that it's a very rich environment. I'd like to learn more than my books can teach me.... So far, I've convinced the people I work with that it's been a very good investment. I'm trying to get them to pony up the dough for a copy of FM Server and a few more copies of FMP because I think it'll streamline our tracking/data collection greatly. I just hope we don't have many more near disasters like this one. I'm still curious about what could have caused the corruption and what I can do to prevent it. I was looking at a very long night getting it all working again. Thank goodness you posted when you did.

Absolutely. The more I work with FMP, the more I realize that it's a very rich environment. I'd like to learn more than my books can teach me.... So far, I've convinced the people I work with that it's been a very good investment. I'm trying to get them to pony up the dough for a copy of FM Server and a few more copies of FMP because I think it'll streamline our tracking/data collection greatly. I just hope we don't have many more near disasters like this one. I'm still curious about what could have caused the corruption and what I can do to prevent it. I was looking at a very long night getting it all working again. Thank goodness you posted when you did.

One of my table has lost all it's fields! The records are still there, as shown in the "define database -> tables" tab, but the fields are all gone.

But the fields are all gone? From the statistics column in the tab listing or from the layout only? It sounds like those layouts won't let you select a table occurence because it doesn't exist in the graph.

When you view the table in the tab list, does it display that there is a table occurence represented in the graph (column to the right, saying 'occurences in graph'? Maybe you deleted the TO from the graph. Everything you wish FM to display on a layout must be represented on your Relationship Graph (even if not joined to anything).

Or ... You may just have a broken relationship. Open your relationship graph and find the table occurence. You can sometimes spot a break because the line to the TO box points to the TO Name instead of a field (strange as that sounds). Even if it seems to be pointing correctly both directions, double-click its connection box (is that the term?) and see how they are joined. Re-specify the join if necessary.

Even if it looks fine, that doesn't mean your Layout is, so then ...

Go back to your layout in which the fields are gone and go into layout mode. Choose Layout > Layout Setup and make sure it's correctly pointing to the table occurence (you just viewed) there. If it broke, you may have to re-select the proper TO from here and may even need to re-point each field to the proper TO.

Just a thought ... I've had this happen is why I mention it; actually on more than one occasion.

One of my table has lost all it's fields! The records are still there, as shown in the "define database -> tables" tab, but the fields are all gone.

But the fields are all gone? From the statistics column in the tab listing or from the layout only? It sounds like those layouts won't let you select a table occurence because it doesn't exist in the graph.

When you view the table in the tab list, does it display that there is a table occurence represented in the graph (column to the right, saying 'occurences in graph'? Maybe you deleted the TO from the graph. Everything you wish FM to display on a layout must be represented on your Relationship Graph (even if not joined to anything).

Or ... You may just have a broken relationship. Open your relationship graph and find the table occurence. You can sometimes spot a break because the line to the TO box points to the TO Name instead of a field (strange as that sounds). Even if it seems to be pointing correctly both directions, double-click its connection box (is that the term?) and see how they are joined. Re-specify the join if necessary.

Even if it looks fine, that doesn't mean your Layout is, so then ...

Go back to your layout in which the fields are gone and go into layout mode. Choose Layout > Layout Setup and make sure it's correctly pointing to the table occurence (you just viewed) there. If it broke, you may have to re-select the proper TO from here and may even need to re-point each field to the proper TO.

Just a thought ... I've had this happen is why I mention it; actually on more than one occasion.

One of my table has lost all it's fields! The records are still there, as shown in the "define database -> tables" tab, but the fields are all gone.

But the fields are all gone? From the statistics column in the tab listing or from the layout only? It sounds like those layouts won't let you select a table occurence because it doesn't exist in the graph.

When you view the table in the tab list, does it display that there is a table occurence represented in the graph (column to the right, saying 'occurences in graph'? Maybe you deleted the TO from the graph. Everything you wish FM to display on a layout must be represented on your Relationship Graph (even if not joined to anything).

Or ... You may just have a broken relationship. Open your relationship graph and find the table occurence. You can sometimes spot a break because the line to the TO box points to the TO Name instead of a field (strange as that sounds). Even if it seems to be pointing correctly both directions, double-click its connection box (is that the term?) and see how they are joined. Re-specify the join if necessary.

Even if it looks fine, that doesn't mean your Layout is, so then ...

Go back to your layout in which the fields are gone and go into layout mode. Choose Layout > Layout Setup and make sure it's correctly pointing to the table occurence (you just viewed) there. If it broke, you may have to re-select the proper TO from here and may even need to re-point each field to the proper TO.

Just a thought ... I've had this happen is why I mention it; actually on more than one occasion.

The TO is still there, just with no fields listed. In the Tables tab of "Define Database", it says "0 fields, 12 records" and the layout that I was using for it is just BROKEN, as in I can't delete it, change it's name, add anything to it. Nothing. Who knows.

The TO is still there, just with no fields listed. In the Tables tab of "Define Database", it says "0 fields, 12 records" and the layout that I was using for it is just BROKEN, as in I can't delete it, change it's name, add anything to it. Nothing. Who knows.

The TO is still there, just with no fields listed. In the Tables tab of "Define Database", it says "0 fields, 12 records" and the layout that I was using for it is just BROKEN, as in I can't delete it, change it's name, add anything to it. Nothing. Who knows.