DEleted/Restored relationships - still can't see the data

[krempch]

HELP

I accidentally deleted some relationships in my Relationships Graph. I manually added the table instances and redid the relationships.

But I still can't see my data that was in the system before, nor can I use some of the scripts to access functions. DI I have to restore to a point in time before I made the deletion, or is there another way to fix what I broke?

(I started looking through the data after I posted - I can see older data, just not new entries).

For example, I click a button that launches an 'add note record' script. I enter the note, and then go back to look for it and it's not posted in the main record's portal where expected.

IS this related to the portal by some chance?

Edited December 17, 2008 by Guest

[Fitch]

The fields and portals on your layouts, as well as your scripts, will not automatically link to your re-created Table Occurrences. You will have to go through all your layouts and scripts and update them to point to the correct reference. Or as you say, go to a backup.

[krempch]

I was afraid of that. Thanks for the confirmation.

[krempch]

Is there a 'utility' that I can use to compare yesterday's data and todays? I would like to do that to identify records that were entered or changed between yesterday's backup and the time of my error. That will make it easier for me to re-import. Thanks.

[Fenton]

Your records should still all be there. So there is no real reason to "compare" them.* You just broke the structure which allowed them to be seen in portals, and possibly some of the scripts involving them. So, as Fitch said, you need to fix the places you broke them, reassigning to the new relationships. If you built them in the first place, this should not be too difficult to do. You fairly easily tell when something is missing its relationship. Think about which is correct first though.

*You really should have a field that records modification times. Best is a Timestamp field, using the option to auto-enter the current Timestamp. Another one for creation timestamp. Makes it possible to do the comparison you mentioned. Otherwise not.

[krempch]

I unfortunately did not write the system - I inherited it from 2 others who didn't know how to spell 'documentation', much less write any.

When I fat-fingered it today, I was trying to document what hooked where -). How ironic.

I ended up getting the last guy who wrote stuff involved again (sizable consulting $$$) to patch it back together. [color:blue]He's not even sure he'll be able to reconnect everything. Is FileMaker supposed to be this difficult? Not much scares me about managing the system EXCEPT this giant hole in my

ability to see the internals of the critter and fix it's heart-attacks.

Wish there was a way to document it and fall back quickly. Other than the DDR and going script by script, I have no idea how I would do that.

As far as audit timestamp, neither creator ever said a peep about it, until today when I called about this. Thankfully the fields I've entered don't go through any new automation ... they're all in the main table. and those I can trace easily.

Sorry to vent ... but Thank you for lending an ear.

Edited December 17, 2008 by Guest

[Fitch]

You'll have to search for newer records in each table manually, using either modification timestamp or date field, or auto-entered serial number or ID field. The latter will only clue you in to new records, not modified records.

[Fitch]

When you delete a table occurrence, a dialog warns you that what happened to you will happen. I don't think it's fair to blame FileMaker for crappy solution design or user errors.