DELETE record will DELETE a RELATED RECORD - Heads up!

[IdealData]

This posting could easily have been put in the relationships section.

Until recently I never realised that the scripted "Delete record" function behaved differently to the menu version....

If you have selected a portal row then the scripted version will delete the related record on that portal row - that's fine because it says so in the FM help system.

If, however, you try to delete record from the "Records" menu the option to delete record is greyed out!

If you were expecting the script to do the same as the menu then watch out!

[LaRetta]

I'm not sure I understand. Whether you manually select 'Delete Record' or create a script with 'Delete Record', it always only deletes the main record because scripts always act on the layout it is fired from. The only way to delete a portal row is by script with 'Delete portal row' (at least that I'm aware of)! I think I'm misunderstanding you or you are observing something I don't see!! I'm very curious where in Help it says this!

UPDATE: Well, it says this: [color:blue]"To delete related records in a portal, Allow deletion of portal records must be selected in the Portal Setup dialog box. " but you STILL can't manually delete a portal row by just being in the row and hitting 'Delete Record.'

It also says: [color:blue]"A related record - Select a portal row in the current table by clicking inside the row but outside any fields in the row. Choose Records menu > Delete Record, then click Delete. " but that doesn't work either.

If you have 'allow deletion on' then sure ... your portal records will be deleted when you delete the main record. FM Help ... isn't.

Edited February 13, 2009 by Guest

[IdealData]

See the attachment for the proof.

The script WILL DELETE the RELATED record when a portal is selected, but there is no native delete available in the portal or the relationship!!!

Untitled.fp7.zip

Edited February 14, 2009 by Guest

[David Jondreau]

Your file doesn't show what you're trying to show. But I see what you're saying.

If you set the portal to allow deletion of records, then the following script will delete related record, but not the main record, using the Delete Record[] script step:

Commit Record[]

Go to Portal Row [First]

Delete Record/Request[No dialog]

[LaRetta]

No, what you say isn't what is happening; at least not on Windows systems. The related records disappear in the portal because the parent is gone. But if you look at the child table, there are still 3 records there.

DJ, thanks, yes, I see it! However, if you put your cursor in the portal field first then run the script with only Delete Record[], it deletes only the parent (as it should).

Thank you both! I think this is inconsistent and bizarre behavior. It means that we should always make sure we commit so the cursor isn't in a portal before we EVER script Delete Record[] or we might be deleting a child instead.

[IdealData]

Have a look back at what I actually wrote to start the topic..

I was trying to explain that the SCRIPTED delete record works on the CHILD record that is currently selected in the portal - WITHOUT A FIELD BEING SELECTED - whereas the MENU based delete record is unavailable in this context.

It seems that FM has the ability to distinguish the "focus".

When a field is selected (even in the portal!) then the delete record will delete the PARENT - however if the portal row is only selected (NOT in a field) then the delete record is ONLY available through a script step and becomes a "delete related record".

None of this explains why you can delete a child record when there is no facility in the portal or relationship.

Please test it again - if it's different on Windows then it needs to known about.

Edited February 14, 2009 by Guest

[David Jondreau]

I was doing my testing in 10A. Which is different than your profile.

I can confirm your results in 8.5A on 10.4.

[IdealData]

Thanks DJ

As it happens I did my tests in v9 - so v10 is different?

LaRetta - anything on Windows?

[LaRetta]

I believe we are saying the same thing and I'm agreeing with you; only that your demo didn't show it because it didn't include Go To Portal Row[].

My big concern is that, if there is a button with Delete Record on the layout, and the User fires the button while their cursor is on a portal row (but not in a portal field), then it won't delete the parent as expected - it'll delete the related record instead (even WITHOUT 'Allow Deletion' on). And I don't think FM should allow deleting related records unless 1) it is specified 'allow deletion' in the relationship or 2) Delete portal row is used.

Yes, HEADS UP PEOPLE indeed!!! I think all Delete Record[] scripts should be followed by a commit to prevent this type of error; as always, we should consider where our cursor is during a script-step and also where our cursor remains after a script finishes.

I can't test it on this Windows box for vs. 10 I had a Bonjour issue and uninstalled and just haven't installed again on it. But I've tested back through vs. 7 and this behavior is consistently inconsistent. Thank you so much for bringing it up! I will NEVER use Delete Record[] without being aware of where the cursor resides (or I'll commit first). :wink2:

Edited February 15, 2009 by Guest

[LaRetta]

I think all Delete Record[] scripts should be followed by a commit to prevent this type of error;

I meant preceded, of course, so that the cursor isn't in a portal row and the parent is deleted as expected, and not the child.

[IdealData]

Many thanks LaRetta.

THERE IS WORSE TO COME YET....

I tested it using IWP - oh dear, oh dear, oh dear...

IWP deletes the PARENT record in ALL INSTANCES - even with a button on the portal row that executes "Delete record". So more inconsistency with IWP. It is okay if you use "Delete portal row".

I'll be sure to use Commit record/Delete record and Delete portal row in the appropriate instances.