Useful Information - One-to-One sets and Xbasic

[Selwyn Rabins]

Here is a piece of information that might be of use to some users who are working with one-one sets and doing data entry into the linking field using Xbasic.


Say you have a set with a one-one link. For example:

order_header----->customer

Tables are linked on "customer_id".

Assume that you have built a form for this set.
Enter a new record. Type in a valid customer_id. As SOON as you tab out of the customer_id field, Alpha Five displays the matching values from the "customer_id" field - as you would expect.


However, now assume that instead of typing in the value into "customer_id", you have an Xbasic script that fills in the value. For example, you might have a button on the form. Assume that the script attached to this button is:

customer_id.text = "1234"

Now, when you enter a new record, then click on the button, the matching data from the "customer" table is NOT shown when you tab out of the customer_id field. Infact, the matching data is only shown when you commit the "order_header" record.

This is probably NOT what you would either like or expect.


HOWEVER, if you change your script to this:

customer_id.activate()
customer_id.text = "1234"

then it works as you would expect.

The reason is that if you want Alpha Five to behave the same in this instance regardless of whether the value in "customer_id" is being typed by the user, or set by Xbasic, then you have to have the Xbasic script give focus to "customer_id" before the value is set, just as is the case when the user types the value.

[rtbtat]

One-to-One set - Bizarre A5 Behavior


I thought that was an informative tip and it is very timely because of an unusal/strange twist that occurred in an A5 application this week. A5 did something every interesting and I still cannot figure out how or why, maybe someone has a valid explanation.

Ok, what am I talking about? A company had a stand-alone table where a lookup field rule entered ALL of the customer�s data every time the user entered a Customer ID during data entry for a NEW record.

This type of record keeping of course violates one of the basic rules for normalizing data, there is no need to repeatedly enter ALL of the customer�s data in every record. Ideally, you should enter ONLY the customer�s ID number and Alpha will then lookup the specific data stored in a customer table.

In order to alleviate that problem, I created a One to One set with tblData as the parent, linked to tblCustomers via the ID number. However, I decided [ think I have a good reason] to add the customer�s name in addition to the ID number for each record, but that�s a minor point.

After I created the new set, I deleted all of the customer data fields from tblData such as address, city, state, zip, etc. As stated above, now we store that information where it belongs in tblCustomers.

Next, I went to the Control Panel and copied the custom form previously used in tblData and pasted the old form into the new set. However, all of the original customer data fields from tblData were still on the form because those fields were in tblData when the form was originally created.

Since those fields were deleted from the table, when I opened the form for the first time inside the new One to One set, I expected to see the word error for every field that previously contained customer data such as address, city, and state.

But this is when the magic event occurred. Guess what Alpha did? A5 replaced all of the customer data fields that were originally stored in tblData with the appropriate fields from tblCustomers.

Isn't that amazing? I never lifted a finger, alpha did it automatically.

Now when the user enters a customer ID, all of the appropriate customer data fields are automatically filled in from tblCustomers in read only fields and displayed on the form. I don't know why that happened, but it�s exactly the type of behavior I wanted. However, I did not have to manually link all of those data fields to tblCustomers, A5 did it for me. Wow!!!

Robert