Major problem-losing records

[Arlen]

I posted a thread on this same topic a few day ago. However I thought it would be best to start a new thread as I have observed some different behavor than previously reported and I have more information

I have been using Alpha Five for many years and have not known this problem to ever occur until I started using version 10 (build 2814-3539)

I have a form with an embedded browse. The browse contains records having an empty date field. When I enter dates sometimes the record disappears. This has happend numerous times but not every time I enter a date. The last occurance of this I entered dates for 4 records and only one record was lost. If I look at the table the record count is unchanged because the lost record is replaced by a duplicate record. In this instanace record number 60 was replaced by a copy of record number 93.

I have lots of questions but no answers.
1. Why doesn't this occur every time?
2. Does it depend on some action just before I enter dates or just after or some combination?
3. Is there something different about the records that are lost ? I don't think so but don't really know.
4. I have a number of very similar forms in my database. Why doesn't this occur with the other forms. Maybe it will eventually since it only happens sometimes with the form in question and I haven't had time to check all the other forms.
5. Is the record always replaced by one 33 records away? Don't think so but don't know for sure.
6. How can I prevent this? I guess the obvious answer is to remove version 10 and go back to version 9. Just chalk it up to a bad decision on my part to buy the newest version. On the other hand I am not 100% certain this did not happen with previous versions. I would need to investigate a lot of backup copies to determine this ... not something I have time to do at this moment.
7. This form (as well as several others) has an onkey script. Could that be a problem even though it worked perfectly in preivious versions? A copy of that script follows:
filter= "egh_ds_form ={} .and.( left(status,6)='active' .or. left(status,4)='sust')"\
+" .and. containsi(exemptions,'*security*')=.F. .and. containsi(lname,'*open*')=.f."

tbl=table.current()
query.order="lname+fname+middle_name"
query.filter= filter
query.options=""

IF a_user.key.value = "{enter}" THEN
a_user.key.handled = .T.
IF a_user.key.event = "down" THEN
browse1.activate()
sys_send_keys("{right}{right}{right}{right}")
end if
end if

IF a_user.key.value = "{F1}" THEN
a_user.key.handled = .T.
IF a_user.key.event = "down" THEN
tbl=table.current()
tbl.change_begin()
tbl.EGH_DS_form=var->TBdate
tbl.change_end(.t.)
sys_send_keys("{tab}{home}")
END IF
END IF


dim shared tempstr as c
dim shared posn as n
dim shared choice as c

IF a_user.key.value = "{ESC}" THEN
a_user.key.handled = .T.
IF a_user.key.event = "down" THEN
choice=""
tempstr=""
qry=tbl.query_create()
' browse1.resynch()
choice.activate()
END IF
END IF

IF a_user.key.value = "{F2}" THEN
a_user.key.handled = .T.
IF a_user.key.event = "down" THEN
browse1.activate()
sys_send_keys("{right}{right}{right}")
END IF
END IF
dim up as c
dim repeat as c
'table.current().index_primary_put("lname")

if this.active()="choice" then
select
case a_user.key.event="down"
if left(a_user.key.value,1)="{" then
'it's a control key or backspace or function key
select
case a_user.key.value="{BACKSPACE}"
if posn>0 then
posn=posn-1
tempstr=iif(posn=0,"",left(tempstr,posn))
a_user.key.handled=.t.
end if
case else
' pass through
a_user.key.handled=.f.
end select
else
posn=posn+1
tempstr=tempstr+a_user.key.value
a_user.key.handled=.t.
end if
case a_user.key.event="up"
up=a_user.key.value
a_user.key.handled=.t.
case a_user.key.event="repeat"
repeat=a_user.key.value
a_user.key.handled=.t.
end select

table.current().fetch_find(tempstr)
browse1.resynch()
browse1.scroll_current_row(1)
choice=tempstr
curs_posn=posn+1
topparent.cursor_set(curs_posn)
choice.refresh()
end if

Note: I sometimes enter the date via the <F1> key and sometimes by typing the date

This is nightmare as I am, so far, unable to reproduce the problelm by my actions. It just seems to happen randomly. Certainly there must be some event that causes this loss of records.

I hope someone has some suggestions.

[Peter.Greulich]

Re: Major problem-losing records

Don't know about your script - dosn't have time to look at it. But I had similar problems involving embedded browse w. date field - AND browse allows data entry/edit. As far as I am concerned it was a bug. Can't say your problem is the same as mine, but it sounds exactly like mine. Cure = do not allow data entry in embedded browse.

[Tom Cone Jr]

Re: Major problem-losing records

Arlen, your script is harder to read than it has to be because you neglected to preserve its format using html code tags. If you don't know how to do that with the message board's advanced editor consider attaching a zip copy of a formatted text file. It will help us give meaningful feedback.

Parts of your onkey event script seem to be manipulating the table beneath the form using commands that talk directly to the table. Other parts of your code seem to be manipulating objects in the form that are based on the same table. I think this is perilous and unwise. Pick one horse and ride it. Don't switch saddles in the middle of the same script.

Your code does not check the mode of your form (or the underlying table) at any point. Some of your scripted statements will fail if the table is already in change mode. It's also possible that your query code is misbehaving if the table is not first restored to "show all" mode before the next query is run.

Can't say these concerns are actual causes of the problems you're seeing, but these are things that I noticed. They're where I'd begin work if I wanted to try to tighten up your sequences.

-- tom

[Arlen]

Re: Major problem-losing records

Tom: Thanks for your very helpful comments. I will revist my code. My concern is that I had no trouble with this same code in previous versions.

[Arlen]

Re: Major problem-losing records

Forgot to add another comment to my previous reply.

I have also discovered that an auto incremented field which is the linking field in my sets has become a duplicate of another record. When this record was originally added to the table this field was correct. I believe it changed in the last couple of days.

[Tom Cone Jr]

Re: Major problem-losing records

Arlen, good luck with your trouble shooting. Fine tuning a specific data entry sequence using the embedded browse object is often very difficult. Peter's idea may, in the long run, be simpler and more reliable.

As you know, the onkey event script will fire after every key stroke. In some of your code you use sys_send_keys() to move the cursor without first verifying which field or column currently has focus. what happens, for example, if the user presses the Enter key after the browse already has focus? Is that different from what happens if the user presses the Enter key when the browse does not have focus? What happens if a change is pending elsewhere on the form and the user presses ENTER? The possibilities are often quite large. They all have to be trapped.