Relationship Corruption?

[exizldelfuego]

I have about 30,000 Item records linked to about 4,000 Group records. It's a fairly large and fairly ugly data set, and when we work in it we find ourselves doing a lot of group reassignments in the items. Some time ago--I'm not too sure as we haven't done a whole lot of work in this database for a while--groups started seeing items they shouldn't. There's no obvious reason for it; the item's group_id is pointing to the correct Group::id. All the data seems to be intact. It's just that FileMaker is deciding that an item belongs to more than one group on its own. I tried breaking the relationship, clearing out the index on the ids, saving the file as compacted; all to no avail. Then I tried recovering, which went smoothly, and the problem is now gone.

 

Has anyone come across this sort of problem? Should I wearily continue working as usual? Should I recreate the database and migrate the data to the new database? I've never had this sort of problem, and I'm finding it a bit disconcerting...

[AHunter3]

039\0\0f\0\0\0À\0/ðtë\0p6ë\0 \0\0éHóâ\0@‹/,\0\0\0\0\0\0\0›ÏVS \0\0\0Ü¢2Àûè\0àÞê\0€

\0\0\0\0\0\0\0\0parseurl\0lor\0\02 \0 \0Þxë\0˜ë\0*\0\0\0\0\0\0\0CtÅ\0\0\0$£2è®7¸±7è

\0\0\0\0\0\0\0\0iconid\0color\0\0\0\0\0 \0\0\0\0X–

Hôâ\0%\0Õ*…2ˆ¬2 \0\0\0\0\0\0$stylevar[htmldoctype]

".((is_browser('mozilla')) ? ("

") : ("

"))."

$headinclude

 

 

 

 

 

 

 

 

 

 

$vbphrase[redirecting]

* $errormessage $vbphrase[click_if_browser_does_not_redirect] *

 

 

 

 

 

 

 

 

".(($postvars) ? ("

 

$postvars

 

 

[doughemi]

OK, Allen, if you say so!

[AHunter3]

What the hell?

 

Umm, that's sure as heck not what I posted!?!

 

Dang. Let's try this again, shall we?

 

I advised a really thorough examination of the Items records that are coming up as related to a group record where apparently the group_id of the Items record(s) does not equal the ID value of the parent Group record. Put the group_id field in the portal (I'm assuming you have a portal?) from Group to Items so you can view it right next to the ID field in the parent record.

 

Are they both number fields, and indexed the same way?

 

Be rigorous: I've got a solution I inherited from prior developers where one table has two different auto-enter serial number fields, one named serial number and one named serial_number. (I have no idea why, aside from sloppiness). I've also seen rel diagrams where one TO is named something horrid like ppo_PTO_RPT_Partitions and a different TO of the same table is named ppo_RPT_PRT_Partitions. Check very carefully that you know for sure that the fields that really are the lynchpins of what really is the correct in-use relationship are indeed showing up as if they matched when in fact they do no.

 

If that's the case, this ain't good.

 

a) How are your files hosted? FileMaker Server? Are they now and have they always been hosted according to best practices? Dedicated computer not used for other things? No file sharing, no anti-virus running on the server, no automated hard drive backups, no defragging of the disk while the db files are open & hosted, no indexing of the files on the HD, never copied the files to another location while they were open & running?

 

b) Did you develop them yourself under FileMaker 8, inherit them from prior developer who did them under FileMaker 7 a couple years ago, or inherit them at the end of a long string of conversions from an original set created under FileMaker 6 or even FileMaker 4 or something?

 

c) Have these files EVER been Recovered and then the actual Recovered files returned to regular use?