Disappearing field data

[idoco]

I am experiencing a strange behavior with a database I am designing. I have used this design before with another database application without problems, so I am not sure if the problem is related to my understanding of A5 or is an actual bug.

At the simplest level, I have a set with one parent and two child tables (CHILD A and CHILD B). The parent table has a one to one relationship with each child. Each child uses the same key from the parent table.

The parent table contains a unique encounter ID and a date. Each child table contains specific data regarding the encounter. Both child tables have working field lookup tables as the source of most of the field data. The remaining record fields are free form text fields.

A modal form, based on the the set has multiple fields. Some are from the parent, some CHILD A, and others CHILD B.

A new record is fetched from the form. Data is entered in multiple lookup fields from CHILD A. No problem. Data is entered in multiple lookup fields from CHILD B. Again no problem.

Now the unexpected part. Upon leaving the field from CHILD B, if focus is now put on a field from CHILD A, whatever the first field in CHILD A that had data entered in it loses it's data. The remaining fields are fine.

If focus is now put back on a field in CHILD B the same thing happens. The first field entered loses its data.

I do notice that when going from CHILD B fields back to CHILD A fields a change record event is indicated on the form status bar. I have tried multiple things including disabling the field after leaving it, cancelling the change record event, changing the referential integrity settings, changing the parent/child relationship. None of these prevent the problem.

The only thing that does prevent the problem is if the first field entered for each child is a free form text field. In this case going back to CHILD A fields then CHILD B fields does not cause the loss of data in the free text fields. The problem only occurs if the first field entered is a lookup table field. It could be any lookup field on the form, but if it is the first entered then it will happen.

Any help would be appreciated.

Barry Oppenheim

[Mike Thomson]

Re: Disappearing field data

Try setting the order of your browse so that it uses an index and not record number

Using record number in browse can cause unpredictable behaviour
It does not help that this is the default sort method

[idoco]

Re: Disappearing field data

Try setting the order of your browse so that it uses an index and not record number

Using record number in browse can cause unpredictable behaviour
It does not help that this is the default sort method

Mike,

Thanks for the suggestion. The records are already indexed on the unique id and not the record number.

Barry

[G Gabriel]

Re: Disappearing field data

You are entering the child then the parent. You should enter a new record for the parent, save it, then enter a child.

[idoco]

Re: Disappearing field data

You are entering the child then the parent. You should enter a new record for the parent, save it, then enter a child.

Gabriel,

Thanks for the input. Actually, the parent data gets entered automatically (the unique id and date are calculated fields). All I am doing is switching between the two child fields.

With that said I did try saving the record after each field entry using the ChangeField event. That seems to be a fix. Still, I don't think I should have to program saving the record for each change.

I also tried switching my lookup fields from a pop up to a drop down type. When I do this the problem goes away. In another words I don't have to save the record with each field event change.

So now the question is why do lookup tables with pop up boxes trigger this behavior, but not lookups with drop down boxes?

If push comes to shove I can work with drop down or use the commit() in the ChangeField event. But I would rather not.

Barry

[G Gabriel]

Re: Disappearing field data

Barry:
You don't have to save the record after each change. What I was saying, when you enter a new record, you need to save the parent before entering a child that way the value for the linking field is established and the link to the child is established.

[idoco]

Re: Disappearing field data

Gabriel,

I realize that you were just referring to the parent record. I tried that, but it did not solve the problem. Only when saving the record after each field change does the problem not occur.

As for establishing the parent record, even without saving, the linking field (which is only calculated in the parent record) shows up properly in both child tables. So I don't think that is the problem.

But in either case it still doesn't explain why this only occurs with pop-up lookup fields and not drop down look up fields. Is there a difference in the events/event order of these two I am missing. Guess I'll run a trace again and see how they differ, if at all.

Barry

[idoco]

One more try?

OK. I have included a simple data set to illustrate the problem. Still without an answer.

Thanks in advance,
Barry

[G Gabriel]

Re: Disappearing field data

Barry:
followed your instructions. You are jumping from Child1 to child2 before saving child1, then going back to child1 and back again to child2.

I am not sure I understand your logic behind that!

[ppittman]

Re: Disappearing field data

If I understand correctly (I haven't looked at the sample dataset), all the data is being entered on the SAME form. If this is the case then it shouldn't matter what fields from the set are being used to hold the input data. Idoco should not have to "save" anything until he/she is finished with data entry. You should be able to enter data into ANY FIELD in the set. The only thing that needs to happen is that the linking field for the child tables is the correct size and data type as the linking field in the parent table.

[idoco]

Re: Disappearing field data

The fact that I am jumping from child 1 to 2 should not make a difference if the form is based on the same set. If the field types are not lookup, but rather text fields the behavior does not happen. If the fields are lookup (based on the same lookup tables), but dropdown (not pop up) the behavior does not happen.

Looking at the trace, the field events appear to be the same regardless of the lookup type. Again, the question is why do pop up, lookup tables only cause this problem?

Gabriel. I appreciate your input. In this application it is necessary to jump between child tables because the acquisition of data is not linear. In other words, the data be captured may come in order (field 1, field 2, etc) or may come out of order (field 13, field 5, field 6 etc). Since the data is being entered as it is acquired the form has to have the flexibility of entering the fields in the record in any order.

Barry

[G Gabriel]

Re: Disappearing field data

Barry:

why do pop up, lookup tables only cause this problem?

This question about the popup lookup came up on this forum many times in one way or another.

While I am not prevy to the internal work of alpha, I cannot offer you a definite answer but it appears that when you are using a popup lookup, you are looking at the value in the external table, the one you are using for lookup, if you move to a different field without saving, that value has not been added to your table yet. You could call this a bug in the lookup table, perhaps it is, but that's how they behave. If you choose to use popup lookup you need to be aware of that. I found lookup previous to be much better in every aspect.

[ppittman]

Re: Disappearing field data

Barry...

I agree with you that it should make no difference how you move through the fields to gather your data. As long as it's on the form then you should not have trouble capturing the data.

Gabriel...

This has got to be a bug. Regardless of whether it's a pop-up or drop-down, the data source is the same. If Barry pops-up a lookup table and selects a value, he should not have to save that value before moving to the next field. What would happen if his user decided to cancel the operation? If, as you say, he must perform a save then he would now have to create a method to "undo" his "saves". That would be utterly ridiculous and a complete defeat of a relational database system.

Barry - report this as a bug. If a pop-up is supposed to act this way then the powers-that-be should alert you to that fact so you can design your application to accomodate this action.

[G Gabriel]

Re: Disappearing field data

Regardless of whether it's a pop-up or drop-down

This does not happen with drop down. If it's a bug, which I believe it is, it's one that dates back a long time and it's only with popup.

The fact that it has not been fixed in such a long time leads me to believe it's not an easy fix since the folks at alpha are pretty good in fixing these bugs promptly. So, if you choose to use popup lookup, which I personally dislike, then you need to be aware of that.

You should report it as a bug, but I don't have high hopes that it will be fixed soon. Many such report have been made already. Who knows, it might get fixed this time around.

[del025]

Re: Disappearing field data

Barry:
The problem with the popup can be corrected by setting the field rules of the lookup field to popup on entrance. If you noticed it was always a problem with the first field in the child table not holding the data - definately a bug. Activating popup on entrance allows the field to hold the assigned value.