Conference iosg::all-in-1_v30

    Arjen,
    
    Before trying anything ...
    ... could you give a specific example? F.i. does it occur in ANY index
    or only in specific ones? What is the key-sequence?
    
    Sjaak.

    Sjaak,
    
    I've actually tried it on the application that we create during the
    application programming course. I will have a go at other ones. But the
    customer actually had the same problem on there own node. The scenario
    is as follows.
    
    1) got to your application
    2) select the index option
    3) do Edit on a record that you select from the list of records in the
    phantom dataset. you will call the entry form from the index form via
    the created menu option.
    4) now, do NOT modify the record, but just press EXIT SCREEN to exit
    from the entry form back to the index form
    5) then decide to stop working with the index from, press EXIT SCREEN
    to go back to your application main menu
    6) now select the same record that you previously, on the index form
    abandoned with the EXIT SCREEN. 
    7) try now to Edit this same record from your normal menu. It will take
    longer than usual for ALL-IN-1 to respond, and when finally the entry
    form is put on your screen, you will find that it is empty, but the
    cursor will be placed in the first enterable field.
    
    The customer obviously has a different application than I have used,
    but has the same problem. 
    I have tried it in two applications, one with a single scrolled region, 
    one with 2 scrolled regions. On the single scrolled region it goes as
    described above. It only seems to be working properly if the phantom
    dataset is actually deleted.
    
    On the 2 scrolled region index form, is seems to be alright. It looks
    like a record locking problem to me. Is there a know function
    (undocumented) that will release the lock on the record?
    
    Thanks for your help.
    Arjen
    

I can't reproduce this using the Nicknames 'application' in standard V2.4. Can 
you spot anything different in your application? Is it only your own 
applications which show this, or can you reproduce it in part of shipped V2.4?

grahame

    Hi Arjen,
    
    I tried it on the Personal Phone Directory menu and was able to
    reproduce it. I think the trouble is caused by the phantom dataset *PER
    that is still opened when you returned to the menu. Closing it using
    the BIND_BREAK function will solve the problem.
    
    I don't know why the phantom dataset isn't being closed, maybe for
    recall index purposes. Unfortunatly, and maybe that is what you want
    know, I don't know if you can unlock the record having the phantom
    dataset still opened.
    
    Sjaak.

    Grahame,
    
    Our replies crossed each other. The reason you can't reproduce this on
    nicknames is because of a BIND_BREAK in the POST_FUNCTION on its
    index-form. Have a look.
    
    Sjaak.

    thanks for confirming this. The disadvantage of doing a BIND_BREAK is
    that you would have to rebuild the data-set.
    
    Oh well, thats life isn't it?
    
    Arjen
    

    Arjen,
    
    ... and don't forget an SPR against the Personal Phone Directory
    for this - please - it's reproducible in DIAMOND.
    
    You'll notice it doesn't happen in the Corporate Phone Directory or
    in Nicknames (as Grahame said) and we know the fix.
    
    regards,
    
    Andrew.D.Wicks (ex-directories developer)
                                                       

    Andrew,
    
    Is there another solution than BIND_BREAK on the data set? I'd be very
    interested to know.
    
    Arjen