DBF Fields Calculated in a Form has no effect in the Table

[SMARTII]

So, I guess This is something I Missed in class:
Ex:
The Table has a julian_Date. That's the way it comes from another sys download.
The Julian date is based on 1 = 01/01/1968
There's about 2 dozen goofy things like this in the Import.
OK, so I have this form or even a custom browse that reformats the goofy stuff into proper information.
Another Ex: 750527004 is corrected to 75052-7004 and 2 other fields each must have the 1st 5 and the other has the last 4.
So, I correct the "longzip" field to 75052-7004, then calc->fill in the other 2 zip fields.
Another ex: an address may be 41 chars long. but the allowance is only 30, so it has to be split into ADDR1 and ADDR2.
HOWEVER, when I open the default browse, NONE of the changes took place in the actual table fields.
booo hoo.
Does all this have to be done in field rules???? to make the changes appear in the table?
That would be the pits since many of the corrections are based on lookup tables.
I really want to avoid a hairball full of calcs & lookups constantly running in a base table every time a multi-user opens it. Seems like a ton of overheasd could develop.
I only want to calc them ONE time in a form, and the table is changed that way.
My circumstance may be a little unique since very little data is manually entered. It comes from outside sources and imported. I thought someone mentioned this (Form calc->changes the actual table value) was available only in V10 but I wasn't really paying attention.

IF this is true about V9, I was thinking about importing into a intermediate table that has the full hairball of calcs/lookups, etc in field rules, then append it to a "finished" table.
The size of the imports vary from 5-40 records at a time.

[csda1]

Re: DBF Fields Calculated in a Form has no effect in the Table

Hi Tom,

If I read between your lines, you are using field rules to repair table data after an import or append of data.

First, if this is the case, see my Field rule recalc tips. Actually, read them either way since you are using field rules at all!:)

Also, if Form Calc changes can modify values in V10 (I doubt it, but maybe something has been added), it is still a bad idea. A very UNCONTROLLED method of an update.

If, on the other hand, you use an Update operation or an Append operation, you can take apply an input data expression for each field (at least you can in the XBasic) that can modify the data (including referencing the destination record's data if appending data to an existing record). This is the right way!

As to the splitting the address into two parts not appearing, I'm sure it has to do with order of processing the Calc's or a bad expression. Either way, it's still the wrong method. My recommendation if you have a too long address, is that you use a USPS Alpha function to normalize the address (which should fit in the shorter 30 character field), and update the value whenever needed, otherwise leave as is. The reason for leaving it as is when possible, are that many people hate seeing their address any way other than how they originally wrote it, at least for more non-junk mail status.

[SMARTII]

Re: DBF Fields Calculated in a Form has no effect in the Table

Ok Ira,
Here's what I did:
1. Import ascii records into an existing Empty table...pretty much a duplicate of the Final User Table.
2. Create an Operation that does all 40+ updates including those that use lookups from other tables.
3. Append those records into the main User table.
4. Empty the Import table for the next import.
Done.
------------------
Now there are times when the imported data values are erroneous and cannot be ascertained until the user examines them in an Input Form.
Ex:
The Imported Taxable sale price is off by a small amt, say, 4.48 out of $36,000.
User corrects the taxable price and bing..the Sales Tax recalcs to an adjusted value...On the Form Screen. But it has to be changed at the table level as well.
I see no way other than a Field Rule level "Calculated field".
It doesn't end there; many times the change "cascades" to effect other field values:
The Total Price has now changed, which affects the registration fees that now change.
Then the user flips the vehicle engine designation to Diesel from Gas and again the change cascades to the registration fees for Diesels which changes the total fees payable again.
So, I see no other way than to have these done by Table level field rules aka calculated fields at least those which are precise numeric calculations.
There are also a few that are auto-calculated that are not mathematical.
Ex:
Some zip codes "cross" counties.
It does happen where the County is wrong and the user flips it to the other County with the same ZipCode.
However, every County has an ID number such as "SMITH" county is ID "055". When the user changes the County to say, "WOMBAT" County, the ID is bing..auto-changed to it's ID which is "311". This is done by Lookup into a County /ID Table, aka a calculation.
I see no other way than to set this up at the Field Rule level as a Lookup. Otherwise, the table's County ID will not change even though it changed at the Input Form Level.
Fortunately, there are only 3 Fields that are Indexed AND the User can actually change their values. And, those are simple 1-field indexes.
RE: Addresses.
Many of the "too long" addresses are those of Financial institutions who are really picky about "normalizing" their address.
But, even more frequently, it's their Company NAME which is "too Long" and has to be split as the State only permits 30 Char Names unless split. So we have to split as the Company will deny the contract if the FULL NAME is not how they want it.
On any printouts the splits are combined into one line.
RE: Other Possibilities:
I may use a SET that has all the otherwise "lookups" linked in the user Input Form. I don't aways like to do that as it can cause a bunch of "record Locks" when Users are in the form that is accessing the same linked data. Example:
80% of the records use the same COUNTY, therefore the same County ID .
So, when 5 users are working the records on their Input Form that have the same COUNTY in the linked table, how does record lock work there? In my old system, 4 of the 5 get "waiting for record lock" and locked out since that COUNTY info is now in an "update" mode by the first user.

Sometimes I just have to count my blessings on this application such as, there is no requirement to interpret the N.T. Book of Revelations.
And, no 660v 3-phase wiring is needed at all!
.

[SMARTII]

Re: DBF Fields Calculated in a Form has no effect in the Table

Ira,
I believe this is what I was referring to for V10 Form ->Field Rules:
Form Level Field Rules

Alpha Five has always allowed you to define Field Rules for the fields in a table. Now, you can also define Field Rules at the Form Layout level.
When you define Field Rules at the Form level, you can define rules for both fields and variables. Contrast this with Field Rules defined at the Table level - this only allows Field Rules for fields, not variables.
Since you can now define Field Rules for the variables that you place on Form layouts, you can now define validation rules, case conversion rules, lookup rules, minimum and maximum values, etc. for variables without having to write any custom Xbasic code.
When you define a Field Rule for a field at the Form level, if there are also Field Rules for that field defined at the Table level, the rules defined at the two levels are combined into a single set of rules.
To define Field Rules for a field or variable at the Form level, simply right click on the object in the Form editor and select the 'Edit Rules' menu item from the right-click menu.
http://support.alphasoftware.com/Wha...l.html#Desktop

Hi Tom,

If I read between your lines, you are using field rules to repair table data after an import or append of data.

First, if this is the case, see my Field rule recalc tips. Actually, read them either way since you are using field rules at all!:)

Also, if Form Calc changes can modify values in V10 (I doubt it, but maybe something has been added), it is still a bad idea. A very UNCONTROLLED method of an update.

If, on the other hand, you use an Update operation or an Append operation, you can take apply an input data expression for each field (at least you can in the XBasic) that can modify the data (including referencing the destination record's data if appending data to an existing record). This is the right way!

As to the splitting the address into two parts not appearing, I'm sure it has to do with order of processing the Calc's or a bad expression. Either way, it's still the wrong method. My recommendation if you have a too long address, is that you use a USPS Alpha function to normalize the address (which should fit in the shorter 30 character field), and update the value whenever needed, otherwise leave as is. The reason for leaving it as is when possible, are that many people hate seeing their address any way other than how they originally wrote it, at least for more non-junk mail status.

[MikeC]

Re: DBF Fields Calculated in a Form has no effect in the Table

Tom,

Contrast this with Field Rules defined at the Table level - this only allows Field Rules for fields, not variables.

Sorry, but not true for global variables. Although not visible as such, all that is necessary is to manually enter the global variable as var->gvYour_Variable_Name. It will be recognized.

[csda1]

Re: DBF Fields Calculated in a Form has no effect in the Table

Hi Tom,

What I said about table field rules applies to form field rules which still should be applied to being for human entered data as well.

Now there are times when the imported data values are erroneous and cannot be ascertained until the user examines them in an Input Form.
Ex:
The Imported Taxable sale price is off by a small amt, say, 4.48 out of $36,000.
User corrects the taxable price and bing..the Sales Tax recalcs to an adjusted value...On the Form Screen. But it has to be changed at the table level as well.

So what is the source of that Imported Taxable sales price? If you are changing that value, if it is a table value, then save the record. If it is a variable, place the needed value back into the source field when the field is exited, or when the record is saved.

All data can be related back to it's source data, that any other values can be built out of for display. When you change a variable or a calc field on a form, it has no "mapping" back to the field as to the relationship.

Thus you must calculate the value to stuff back into 1 or more source fields. If in change/enter mode, it can be done to the fields. If in view, you'll need to open the record in change mode, modify the source fields, and save.

Does that make sense for you?

[SMARTII]

Re: DBF Fields Calculated in a Form has no effect in the Table

I believe so...I'm off to try it...
Thank you.