Data entry delay

[werder101010]

I have spend a lot of time building a form and had no problems entering data. This changed today. When I make a new record it now takes a couple of seconds before I can start entering data. I noticed that alpha somehow screens all the fields in the form before allowing data entry. In the attached example I use date fields because this made the problem more visible.

When I make a new form from scratch the problem disappears. When I delete all the fields on the problem form and place new fields on the form the problem will remain.

I worked on a solution for five hours and used: empty table, database compact, update indexes, rebuild the set, installed the latest patch, recovered a backup database and restored a hard disk partition with an earlier A5 version. It did not solve the problem so maybe you no what button to push?

[trackmanpete]

Re: Data entry delay

I tested your sample and found no problems that I can see. I am able to enter dates without any hesitation. I am using the latest patch without the new browse code.

[milesjg]

Re: Data entry delay

werder;

I can't find any problem either. Using 2007-3252 new browse.

[Tom Cone Jr]

Re: Data entry delay

Werder42,

Took a look. You're doing several things that are unusual, and frankly, they are things I would not recommend.

Your form is based on a set. But there are no fields from the parent table in your layout. If you wish to use a form to enter records into a single table, you should strongly consider basing your layout on that table. The delay in assigning the auto-increment field value to the new "child" record when the new record is begun results from having based on the form on the set.

I see in the parent table you've defined an auto-increment field rule. It's often best to also define a data entry field rule for the auto-increment field to force Alpha Five to "skip" the auto-inc field during data entry. Doing so prevents the user from editing the auto-inc field value and often improves the integrity of your linked relationships.

[werder101010]

Re: Data entry delay

Thanks for taking a look Pete and Miles. Tom, I really appreciate your comments on my configuration! Maybe you can take at look at my new example. It explains why I did what I did. I hope you can tell me if it makes any sense.

It's for a law firm. It starts with one appeal. When the case is won it ends right there. When the case is lost there can be two more appeals. These three appeals must share the same ID. Thats why I've linked the three appeals to the parent.

For every appeal there can be one invoice. That's why every appeal has is own �bz_code�, �br_code� or �hb_code�. This code is used to establish a unique link from the invoice table to the corresponding appeal table. I use �set field� to copy the necessary fields from the appeal table to the invoice table.

Does it make any sense or will it cause integrity problems?

[trackmanpete]

Re: Data entry delay

Tom:
I took a closer look at the sample to try and understand what you are saying. I did notice how there seems to be a running cursor down all of the fields on the sample form prior to the cursor finally ending up in the autoincrement field at the upper left. I didn't notice that the first time around.

I don't fully understand what you are saying in that the parent table only has one field, which is the auto increment id field. The other fields are all of the children fields.

So, as a learning experience only, why does the cursor run down all the child fields when a new record is created?

I made the two id fields read only and then created a tab order that went from the first date field to the last, but that still made the small calendar icons flash when I selected to create a new record.

Just an interesting observation and wondering....

[Tom Cone Jr]

Re: Data entry delay

Pete, there are no fields from the "current" record of the parent table present on the form. BZ_ADM_NR is not an auto-inc field.

[werder101010]

Re: Data entry delay

Tom:
Why does the cursor run down all the child fields when a new record is created?

Pete explained the question more clearly and I'm still very interested in a solution. In the provided example the delay is maybe 0,3 seconds but in my application with more fields it runs up to 3 seconds.

Werder42,

Took a look. You're doing several things that are unusual, and frankly, they are things I would not recommend.

In the example database (data entry delay.zip) I removed most tables because I didn't need them to point out the problem. Maybe that�s why the set looked a little strange. Now I've added some table's to the set (new form.zip) and would like some confirmation there�s something or nothing wrong with it.

It's for a law firm. It starts with one appeal. When the case is won it ends right there. When the case is lost there can be two more appeals. These three appeals must share the same ID. Thats why I've linked the three appeals to the parent.

For every appeal there can be one invoice. That's why every appeal has is own “bz_code”, “br_code” or “hb_code”. This code is used to establish a unique link from the invoice table to the corresponding appeal table. I use “set field” to copy the necessary fields from the appeal table to the invoice table.

Does it make any sense or will it cause integrity problems?

So don�t be shy to point out a problem and don�t be afraid to state nothing is wrong.

[Tom Cone Jr]

Re: Data entry delay

Pete explained the question more clearly and I'm still very interested in a solution

Does the "problem" go away if you base the data entry form on the table, instead of on the set? I believe the absence of any fields from the parent table is the culprit here.

[werder101010]

Re: Data entry delay

The problem will go away as soon as I build a new form. In either way I�m not sure how long it would take for the problem to reappear.

If I understand you right the problem can not be corrected by placing a field from the parent form onto my current problem form. But if I rebuild my form and include a field from the parent form from the beginning the problem should not appear again.

[Tom Cone Jr]

Re: Data entry delay

Werder, a more accurate statement of my concern is this. 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.

[milesjg]

Re: Data entry delay

Tom Cone Jr.

Greetings.
You said "It's a mistake to use a set based form to do data entry", etc.
What are the problems that occur when doing such. ?
What causes them. ?
Not to seem priggish, but what exactly are the issues/reasons/obeservations/experiences/refferences,etc that makes this a mistake. (If you don't mind taking the time.)

Thanks in advance

[werder101010]

Re: Data entry delay

Hi Tom,

When somebody builds a set to solve problem �A� and you comment on that set, please use your expertise to not only say what's wrong with that set but please also say how problem �A�can be solved.

Furthermore my form (based on a set) is not used to enter data in one table. It is used to enter data in three different tables.

If I really understand your explanation correctly I can also remove the client field from the three tables (�adm_bezwaar�, �adm_beroep� and �adm_hoger_beroep�) and make that field part of the parent table. When I include this client field on the form en make sure my first data entry is in the client field / parent table everything should work fine. If this is a solid solution I understood your explanation correctly and I would really like to understand it. Otherwise please inform me on my misconception.

[milesjg]

Re: Data entry delay

Tom

A p.s. (post sausage) that I should have added.
We have a app that is literally dead in the water due to data entry problems. The delay in data entry moving from row to row on embeded browses is about 5-7 seconds. Same with entering data (keypress time until data appears on the screen is about 3-4 secs). This began with the illustrious new browse logic. (3216) The forms are, as you mention, are based
on sets. The only recourse open is to redo major parts of the program and try and avoid any black holes. (I'll leave that def open) Thus the interest in form/table configurations for data entry.

Thanks again

[Tom Cone Jr]

Re: Data entry delay

Perhaps I've been confusing things, because my replies have all been based on Werder's first example. Some of you may be talking about his second example. If so, I apologize for the confusion.

In Werder's second example I see the problem he describes. Each of the fields on the form is given focus one right after the other whenever a new record is begun in the parent table. This seems wrong to me. When I trace the events that are occurring what we see on screen is confirmed. Each of the type in fields are given focus one right after the other. Very strange. No answer here. Will ponder.