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.
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.
Comment