Jump to content
Salesforce and other SMB Solutions are coming soon. ×

Relationships finds ghost records.


donwolfkonecny
 Share

Recommended Posts

This worked fine in 5.5 but I converted to 8.5 and get irritating results. In my Member file I have a field that displays concatenated ProblemTexts from a Sustainer file and Xaction file. If there are no errors in any of the related records, the ProblemText would be blank. However, I am finding that if there is NO related record, then a ProblemText (from a nonexistent record) is reported. I can't figure out why.

 

If I display (through the relationship) the ProblemText of the related record, it shows the ProblemText. However if I try to display the Key field of the non-existent related record, the field is blank.

 

It's as though it is relating to a record that doesn't exist and will display unstored calculations from the non-exisitent record, but no data fields.

 

Any ideas?

Link to comment
Share on other sites

sure.

 

at the parent file, AllProblemText is currently = Sust Problems::SustProblemText

 

it is text, single repetition, and i have experiemented with the "calculate even when all referenced fields are empty" with no change. Of course it is not indexed.

 

in the daughter file, I have simplified is so the calculation SustProblemText merely returns a piece of text "problem here". This field is not indexed, it is text.

 

The relationship is from an idnumber like "c207485" that is text in both records and indexed minimal. I don't know how to reindex beside unindexing then indexing again, would that screw up relationships in the meantime?

 

Note that if there IS a related record, then the ghost message does not appear. It only appears when there are no records related by the key. Then a field that merely reports the text of a calculation in a related table/file gives the text even though there is no related record.

 

Another thing is that if I press GotoRelatedRecord on that text, it goes to the daughter file with 0 found count.

 

Is this some kind of conversion funkiness or something even more damning?

 

Hi

 

Can you post the calculation for ProblemText and can you be a bit more specific about how the tables relate to each other?

 

maarten

Link to comment
Share on other sites

I'm sorry, I can't reproduce this problem. I created a two-file tester with serial ID as key between main and child file. An auto-enter calculated text in the child file; it shows up fine if the child record holds an existing main ID, and it is emptyif it isn't. Both in the related field in Main and in a calculation, =Child::SomeText

 

So it could be a leftover from the conversion; but I really can't say without seeing more of what you really have built.

 

kjoe

Link to comment
Share on other sites

I'm sorry, I can't reproduce this problem. I created a two-file tester with serial ID as key between main and child file. An auto-enter calculated text in the child file; it shows up fine if the child record holds an existing main ID, and it is emptyif it isn't. Both in the related field in Main and in a calculation, =Child::SomeText

 

So it could be a leftover from the conversion; but I really can't say without seeing more of what you really have built.

 

kjoe

 

You are right. When I create fresh the simplest example of my solution, this problem does not occur.

 

I will try duplicating my solution and stripping it down to see if I can reveal the problem.

 

If anyone knows of glitches with non-related records appearing as related records, please let me know.

 

Thanks for the ideas.

 

donWolf

Link to comment
Share on other sites

Have you clicked on each field in the portal and made sure they are based upon the exact same relationship indicated for the portal?

 

Another thing is that if I press GotoRelatedRecord on that text, it goes to the daughter file with 0 found count.

 

There are no related records - at least not directly. One must test if there are related records before a GTRR jump; something like:

 

If [ not IsEmpty ( child::uniqueID ) ]

Go To Related etc

Else

Show Custom Dialog [ "No related records found" ]

End If

Link to comment
Share on other sites

  • 2 weeks later...

okay I have some files that demostrate my problem. I can't figure out how to post them. Can someone give me their email to send them to or is there some way to post them somehow to this site? What's the typical solution in this situation.

Link to comment
Share on other sites

or is there some way to post them somehow to this site?

 

If you become a member, you can post samples of your problem and download solutions. smiley-laughing

Link to comment
Share on other sites

Can someone tell me why the message appears in in the membership level when there is no related record to supply the text?

 

Files now supplied!

 

login name = test

no password

Link to comment
Share on other sites

Password? smiley-smile

 

I got in a hurry and didn't read your entire post before I downloaded. I can't even delete my own post. I could have blanked it but ... I wanted everyone to see that I can be a nerd (just in case you didn't already know that) because I asked for password before reading - just like most Users do. smiley-tongue-out

Link to comment
Share on other sites

Ah yes. Very peculiar. It must be because you are joining two auto-enter fields MemberID to SustKey (which can't work but obviously does in a strange way). When you add a MemberID in Sust and join them, it works properly.

 

But your calculation (unstored) in Membership is looking for the FIRST related value, ie, Sust Problems::ProblemText. So Pledge Amount Original = 0 is the first related (although shouldn't be related) record. When you join MemberID to MemberID it works fine. It acts like it used to be cartesian and just didn't change when you changed it to =. Because c939393 (text, memberID) should NOT relate to Sust Key (text) when Sust Key contains xxxxx.

 

So again, it displays very strange behavior when joining this way. It RELATES THEM even though using =. Use MemberID in Sust and you'll be fine ... and thank you for showing me something very weird!! I adore weird things.smiley-laughing

 

By the way, I replicated the behavior in two new test files. Maybe this is something I can use (in my twisted sort of way). So Cool! I would think cartesian is easier tho but still ... it may have its strange uses.

Link to comment
Share on other sites

Very weird. Even with NO Sust record displaying the calc, it produces the calc in Membership (the Sust field placed on the main layout). Unless there is something more here I can't see, it is wonderfully weird and I can use it - the fact that it displays the calc when there are NO related records (with that calc result) and there are NO related records at all! My test file does the same thing!

 

Maybe somebody can spot something ... but this is not normal. And believe me, I KNOW not normal. smiley_cool

Link to comment
Share on other sites

For those that think Don and I've been smokin' whacky-weed, here is the test file (so it isn't a matter of one trashed file or layout). Notice one record in each file and notice that Sust calc from Text 2 on the test1 layout. It should be empty. The relationship is between Mem and Sust on =. Ummm, I didn't rename the calc in test 2. Where it says Test2calc - that's the label of the calc which should produce "Pledge Amount Original = 0" . It's the same field as the one sitting in test1 called Sust calc from test2!! It doesn't display results in test2 because THE ONLY RECORD has an amount in Pledge Amount Original so is failing the evaluation. IDs are both text, everything is right...

 

But since the ONLY record in Sus isn't showing that calc, where is it coming from? I think it is coming from a ghost 'last visited Christmas passed.' Why do I suspect wonky connection between two auto-enter (which shouldn't be done) and Last Visited? Because I don't suspect anything else. Opps!

 

Apologies for zipping it - to keep the size large enough to see, it was too big for Cafe'.

Link to comment
Share on other sites

I'm not sure but it seems to be related to the calc in Sust having "do not evaluate if all referenced fields are empty" unchecked. I'm a little cross eyed right now, that's all I noticed.

 

maarten

Link to comment
Share on other sites

Yes. But that shouldn't make it evaluate to a non-existant record - calculations can only evaluate on records. The only record evaluates as blank. I think that is a symptom (that's how we found out about it) but not necessarily the problem behind it. Because the relationship shouldn't be working and NOTHING should be showing in that related field.

Link to comment
Share on other sites

true. that's what crosseyed means I guess. :D

But...it really goes away if you store the calc in Sust. Is there a reason why it shouldn't be?

 

Maarten

 

PS still not an explanation of the phenomenon.....

Link to comment
Share on other sites

Oh kjoe ... you're talking about correct syntax and we're seeing a wonky in action. Yes, once my excitement settled down and Don responds about why he's attempting to join two auto-enter fields, then I was going to expand on some of this stuff. smiley-laughing

 

The thing is ... it is unusal things like this which teach us about FM internally. It helps us see how it evaluates. And these are GEMS to me (and should be to everyone). We could just shrug it off and move on and miss some great opportunity here. Phenomenon is right. I plan on taking Last Visited to bed with me ... I think FM internally holds onto Last Visited possibly (keeps it in its internal memory perhaps). Okay, call me whacky ... it won't be the first time. smiley-smile

Link to comment
Share on other sites

I was going to expand on some of this stuff

 

I'm going to wait for that! What's a wonky?

 

Time for some breakfast

 

Maarten

Link to comment
Share on other sites

Wonky is something from the *ether which lives outside the bounds of normal ... kinda like me. So Cool!

 

* Stationary Luminiferous theory - Einstein Relativity Theory

 

Okay, wonky is how *I* describe these theories... Opps!

Link to comment
Share on other sites

"I think it is coming from a ghost 'last visited Christmas passed.'

 

I'm wrong here - removing Last Visited from auto-enter makes no difference. That's what happens when one spews theory and supposition before testing thoroughly. And it's not even because of auto-enter or the = 0 in the calc. Is it context?

 

But this unexpected behavior is important because, what if there are other areas in which ghost calcs display (when there isn't even a relationship). Won't it matter? You bet it will. Why is it evaluating like this? Why's drive me insane because they MEAN something. :D

Link to comment
Share on other sites

OK here's a test file. I've narrowed it down to this: it only happens when you test IsEmpty in the child table and don't store this. Any other calc or test won't show up if there are no related records, stored or unstored, boolean or normal, evaluate always or not, validated or not. Still haven't got an explanation, but maybe this will help you make one.

If I had to make a guess I'd say it attempts to evaluate the unstored calc (since it is unstored) and as there are no related records, it returns null so IsEmpty returns true. something like that. but I'm not known for being spot on often in this type of conundrum. Welcome to the wonderfull world of wonky :P

 

 

Maarten

 

PS in any case the name ghost record is not apt, it is a ghost evaluation if anything.

Link to comment
Share on other sites

Yep, it is most certainly a bug. And it is a bug that has carried from 8.02, 8.03 and now to 8.5. And you are correct that it is not a ghost record but rather a ghost evaluation. I should think FM knows about it but I will report it nonetheless just in case they don't. Because if they knew, it should have been fixed and not passed on through the versions.

 

Thanks kjoe! Don, that calc you are using? Don't (smile). Instead try:

 

If ( not PledgeAmountOriginal ; "Pledge Amount Original = 0" )

 

... and CHECK 'Do not Evaluate' and don't join between two auto-enter fields - it'll never work that way if you are using =. And the calc should NOT be unstored.

 

LaRetta smiley-smile

Link to comment
Share on other sites

bug that has carried from 8.02, 8.03 and now to 8.5.

I just tested it in dev7, it's present there also. Since Donwolfkonecny started the thread stating it worked fine in v.5.5 I'm assuming it crept in in the new structure from .fp5 to .fp7. thanks for reporting, I would not know how to do that by the way. You got an URL for this?

 

Maarten

Link to comment
Share on other sites

Oh kjoe ... you're talking about correct syntax and we're seeing a wonky in action. Yes, once my excitement settled down and Don responds about why he's attempting to join two auto-enter fields, then I was going to expand on some of this stuff. smiley-laughing

 

The thing is ... it is unusal things like this which teach us about FM internally. It helps us see how it evaluates. And these are GEMS to me (and should be to everyone). We could just shrug it off and move on and miss some great opportunity here. Phenomenon is right. I plan on taking Last Visited to bed with me ... I think FM internally holds onto Last Visited possibly (keeps it in its internal memory perhaps). Okay, call me whacky ... it won't be the first time. smiley-smile

 

Wow thanks LaRetta for so much investigation! The reason the sust error text is not stored is because in the real solution it involves other tables and therefore cannot be stored.

 

I had forgot that sust key was auto-filled from prior but that shouldn't cause this problem. (In the real solution sometimes the user creates a new record at the sust level and I want it to be a daughter of the same parent (although I could copy and paste). Regardless, it's a provided supported option and should not cause this bug. Normally a sust record is created through a portal at the membership level and automatically creates a matched key.)

 

I removed the auto-fill and that did not fix is so I don't think that is the problem. I changed it to "don't calculate if no fields" and that works, although if I do the same thing for my full error calculation then I still have the problem so apparently there is something in the larger case statement that is still generating the problem. I will try to tinker with more later and post update. Thanks for helping confirm I'm not crazy or corrupted file or other hardware error.

Link to comment
Share on other sites

OK here's a test file. I've narrowed it down to this: it only happens when you test IsEmpty in the child table and don't store this. Any other calc or test won't show up if there are no related records, stored or unstored, boolean or normal, evaluate always or not, validated or not. Still haven't got an explanation, but maybe this will help you make one.

If I had to make a guess I'd say it attempts to evaluate the unstored calc (since it is unstored) and as there are no related records, it returns null so IsEmpty returns true. something like that. but I'm not known for being spot on often in this type of conundrum. Welcome to the wonderfull world of wonky :P

 

 

Maarten

 

PS in any case the name ghost record is not apt, it is a ghost evaluation if anything.

 

Okay I have confirmed this with my files. It took a bit longer because I had several fields being validated by NotEmpty. These fields were used in logic tests by an error field that displays errors about any business-logic errors (missing billing amount etc). References are made to other tables which means the error field cannot be stored. I think this is all legitimate and acceptable and reasonable, yet it results in an error for all my Membership records which do not have a related record. To me this seems like a bug.

 

To clear this problem, I have to remove from all my fields the validation of NotEmpty. This functionality is provided yet results in an error message in most of my records. I hope LaRetta's submission gets this resolved for an upgrade. Until then I guess I have to stop using NotEmpty since something is broken.

 

Thanks everyone for all your help!

Link to comment
Share on other sites

This thread is quite old. Please start a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share



×
×
  • Create New...

Important Information

Terms of Use