Data entry delay

[werder101010]

Re: Data entry delay

Thanks for the update.

[Tom Cone Jr]

Re: Data entry delay

Werder, the "wandering insertion caret" seems to be happening because Alpha is following internal rules that tell it where to shift focus when a new record is begun. Your SECOND example seems to fall into a crack that I've never seen before. Way to go!!! Some people have all the luck !!!

Your form is based on a set. The parent table has only one field in it. That field is on the form. In field rules you've made the field an auto-inc field and you've set the "skip" data entry property "True". So, what seems to be happening is this. When you click the New Record button on the toolbar a new autoinc field value is assigned to the only field in the new parent table record. Focus now must shift somewhere else on the form since focus can never land on the autoinc field in the parent table while SKIP is true. So, Alpha starts looking. It's actually looking for other fields in the parent table record. Since it can't find any it finally defaults to a field in one of the child tables in your set design. The problem goes away immediately if you have a second field in the parent table that's placed second in the tab order on your form. I've reported the behavior to tech support. Whether anything is done about it remains to be decided. It would not be surprising for this to fall to the bottom of the priority "totem pole" since very very few designs would only have one field in their parent table. -- tom

[trackmanpete]

Re: Data entry delay

Tom:
Thanks for providing such a clear description of what takes place with the original sample.

[milesjg]

Re: Data entry delay

Tom C

Normally if someone ignores a question I forget about it. In this case you made a statement about a pretty fundamental feature/function/aspect of A5.
when you said;
"It's a mistake to use a set based form to do data entry into a single table that happens to be a member of that set. Base this kind of data entry on the table itself, not the set it happens to belong to."
I could'nt find anything in the A5 "documentation" in regards to this. Considering one has the option to create a new form on a table or set, with no warning in respect to data entry, perhaps you have insight into something
other A5 users would be interested in.

[Tom Cone Jr]

Re: Data entry delay

James, sorry. I forgot about your question and got busy on other things. In the case at hand the original example had a form that was based on a set of tables. The parent was linked one-to-many to a child table, if I recall correctly. The form contained fields from only the one-to-many child. I cautioned against this design. If you want to do data entry into a single table, base the form on that table. Don't build a form based on a set of tables, but only use it to enter or edit field values from records in a single table, especially, a child table. My reasoning is this (a) when the set based form opens all the tables in the set get opened across the network, even though the form only provides for inputs to fields in a single table. Opening more tables than necessary is inefficient and may interfere with other activities on the network. (b) more importantly, the "current" parent table record is invisible. The user can't tell which parent table record the "current" child table may be linked to. (c) If new child table records are entered through the form they will be "linked" to the invisible parent table record that happens to be "current". This seem fraught with peril to me. How does the user know they're entering line items to the right invoice header? The header record can't be seen. The possiblilty for error seems unacceptedly high. (d) In the case of a one to many link the only child records that will be visible are those linked to the current parent record. The user can't navigate to child records linked to other parent table records. This will be confusing to the user. I can imagine folks thinking that line items have been "lost" or "disappeared" and re-entering them from scratch. Of course this would link them to the wrong header record, leading to serious problems in the integrity of your data.

In short the "mistake" is to use a set based form when you only present fields from a single child table for the user to see and / or edit.

-- tom

[werder101010]

Re: Data entry delay

Great Tom, it works ! Thanks for your time, explanation and solution !