Unreachable Child Records in Set

[Steve Andrews]

I'm seeing something happen for the first time in my Alpha experience. After a user deletes a child record, that record appears to be duplicated! Moreover, one of those two duplicate records cannot be selected nor scrolled to! If there are records before and after that record on the browse, it will simply skip over that "dead" record.

When I browse the child table alone, only one such record appears. But when I browse the set, both of them appear and, again, one of them cannot be scrolled to. Hmmmm? This is very odd!

When the user deleted the record, she used a button which I set up to assure that the parent record would not get deleted. In the button script, I assign tbl to the child table using a table.get() and verify that it is pointing to the record the user wants to delete. The code then follows with:

if dlg_result = UI_YES_SELECTED
	nRcd = tbl.recno()
	nMode = tbl.mode_get()
	if nMode = 0
		tbl.change_begin()
	end if
	if nRcd = tbl.recno()
		tbl.delete()
	end if
	if nMode = 0
		tbl.change_end()
	end if
	topparent:Browse2.refresh()
else	
	ui_msg_box("Nothing Deleted","User cancelled request for deletion.")
end if

My only speculation is that maybe by using table.get() for the tbl pointer it is locked into the current session and cannot behave the way it would if it independently used table.open(). Regardless, why would the set indicate a record which the child table does not show?

BTW, when I packed both the parent and child tables, the "dead" record went away. But later when another child record was deleted, the same thing happened.

Steve

[Clunes]

Re: Unreachable Child Records in Set

You will get the appearance of two records from one in the set if you somehow have two parent records with the same link ID number.

[Tom Cone Jr]

Re: Unreachable Child Records in Set

Hi, Steve.

I'm puzzled by all the IF ... END IF code blocks. Why are they necessary? And shouldn't the mode test in the last IF ... END IF block be for 1, instead of 0. After all previous statements put the table in CHANGE mode, right?

I'd re-write the script as follows:

if dlg_result = UI_YES_SELECTED
	nRcd = tbl.recno()
	nMode = tbl.mode_get()
	if nMode = 0   ' VIEW MODE
		tbl.change_begin()
	        tbl.delete()
	        tbl.change_end(.t.)
	end if
	topparent:Browse2.refresh()
else	
	ui_msg_box("Nothing Deleted","User cancelled request for deletion.")
end if

Am I missing something here?

[Steve Andrews]

Re: Unreachable Child Records in Set

I'm puzzled by all the IF ... END IF code blocks. Why are they necessary?

Hi Tom,

You're right that they are somewhat unnecessary. Just to be ABSOLUTELY sure that the table was still pointing to the record to be deleted, I put in the extra IF...END IF. With all that happens in Alpha, I wasn't sure that the pointer wouldn't jump from the time of verification to the time of deletion. But that check could be removed as you did.

But in you code, no deletion takes place if the table is in, say, edit mode. For that scenario, my code would still do the delete but would avoid the CHANGE BEGIN and CHANGE END statements. If I didn't do it the way I had set it up, I would at least have informed the user that no deletion took place due to the mode (which could be accomplished with another ELSE and UI_MSG_BOX added to your code).

Clunes: There is no evidence of two parent records with the same linking field. Even if that were trhe case, why would the only duplicate child records be those which have been deleted?

If this only happened while in the session for which the record was deleted, I would look more at resynching the data and the browse. But the "dead" records show up on other machines, after rebooting, etc. So there's something within the set itself which has been adversely affected. Very strange!

Steve

[Tom Cone Jr]

Re: Unreachable Child Records in Set

Steve,

Two quick comments:

1) I never let users delete a record if its in change or enter mode. Perhaps this has become a bit of a blind spot for me. But it's served me well over the years.

2) I don't understand why your code would "end" the change but only if the table was still in "view" mode? It seems to me that if the mode is 0 then you can't "end" the change, after all, no change is pending.

  if nMode = 0
		tbl.change_end()    <=======
	end if

[Steve Andrews]

Re: Unreachable Child Records in Set

Tom,

1) I never let users delete a record if its in change or enter mode.

You mmake sense and I'll probably alter my code in this regard. But as I mentioned above, I will at least give a message to the user as to why the record was not deleted if that is the case.

2) I don't understand why your code would "end" the change but only if the table was still in "view" mode? It seems to me that if the mode is 0 then you can't "end" the change, after all, no change is pending.

If you look at my code more closely, when nMode = 0, the CHANGE BEGIN statement is executed. That puts it into change mode. That is why I hold the mode in a variable so that it reflects the mode BEFORE THE CHANGE. Hence, at the point where you got those line of code from, if nMode=0 then tbl.mode_get() would return a 1.

While these are notes on coding style, they say nothing about the strange behavior of the set.

Steve

[Tom Cone Jr]

Re: Unreachable Child Records in Set

I see, thanks.

-- tom

[Steve Andrews]

Re: Unreachable Child Records in Set

Mystery MIGHT be solved!

When viewing the child table via default browse there were 15 records for this client, none of which were the "dead" records which repeated. Then upon doing a <tbl>.fetch_next loop through the child table while this client was in focus, one of those records repeated three times! In other words, on three successive hits of <tbl>.fetch_next, the same record number was pointed to. Hmmmm?

Well, upon rebuilding the indices, the "dead" records no longer appeared and all looked well. I can only hope that the problem doesn't resurface when more child records are deleted from within the form based on a set. More testing will prevail tomorrow to see if all is well.

Steve

[Steve Andrews]

Re: Unreachable Child Records in Set

Well, so much for the empty hope. It is true that these "dead records" no longer show up upon rebuilding the indices. But a user yesterday said that the problem resurfaced. Upon entering a new child record, three appeared on the screen - two of which could not be selected within the browse. And when viewing the default browse of the set, the same behavior occurs.

Seeing that some other people have resorted to rebuilding forms from scratch when having major problems after upgrading to V10, I'm tempted to do so in this case. I may rebuild the set as well as the form. Also, if I find some time, I may try replicating this on a smaller application with non-sensitive data so that others can see it (and to possibly send in a bug report).

Steve

[Steve Andrews]

Re: Unreachable Child Records in Set

Well, I think now that the mystery is solved!

In a separate situation, a report based on a different set was showing a record which didn't appear on the screen. I couldn't delete that child record whatever I tried - operation, script, default browse, etc. Later, I realized that it was, in fact, deleted but still showed up on certain browses and reports. So I added ".NOT.deleted()" to the filter of the report and all went well.

I then suspected deleted child records to be the problem with my original posting. Low and behold, upon going to the properties of the form, selecting "filter/order", and putting in ".NOT.deleted()" for the filter of the child table, the problem seemed to go away. No longer did those "dead" records appear in the embedded browse!

Seemingly, if a child record were deleted in V5, it would never show up on layouts. But in V10, the layouts have to filter them out if the child table has not been packed since the last deletion. Whoa! I will eventually have to enhance the filters of MANY forms and reports because Alpha will not exclude deleted records!

Steve

[Ted Giles]

Re: Unreachable Child Records in Set

That's a good result Steve.
Thanks for posting the answer, it may help others, and that's key to the Forum - shared knowledge