Hello,

I am developing an application and it has a field that users used to
fill out themself. Now the design of the database improved such that
the field can get the value from a calculation or from user input.

So I tried to use the autoenter option with a calculation that allow
users to overwrite. The problem is that the calculation is not
computing on existing records.

Do you know how to fix this? In the past I used a script (to copy
values) but it does look like brute force to me.

thanks!

auto-enter calculations are evaluated when the record is created. If
you want to populate existing records the best way to do it is to go to
a layout where the field is exposed select it and then do a Replace
Contents using the calculation that you wish to auto-enter. If you do
not want some of the existing records to be updated then you will have
to omit them before doing the Replace.

I think this works: Go to Define database. Copy the formula from the
Auto-Enter field then change the field to Calculation. Paste the formula
into the calculation specification (which should then update all
records). Now change the field back to auto-enter.

Otherwise you may need to do a record update (Browse all records, View
as Table (optional but handy), click in one cell of the field to change,
select RECORDS / REPLACE FIELD CONTENTS and paste your formula there.

What is wrong with brute force?

Michael Paine

F.Balaguer wrote:

In article <1131579733.367674.171730 (AT) f14g2000cwb (DOT) googlegroups.com>,
dan (AT) owlsnet (DOT) co.uk says...
Auto-enter calculations are evaluated upon creation and whenever a field
they depend on is changed.

Yes. The best way to do it "retroactively" is as you describe.

The best way to do it "going forwards" is to uncheck the "Do not replace
existing value for field (if any)" box which is right next to where you
specify that the autoenter is by calculation.

Then entering data in any field it depends on (including *itself* if it
the autoenter calc references itself) will update the field.

-regards,
Dave

You are right I did not say everything that could be said about
evaluation of Auto-enter, but the specific question was how do I fix
the fact that it is not calculating on existing records? and I did not
want to muddy the waters. The problem with unchecking the Do not
replace existing value is that if the calculation does refer to itself
then great care has to be exercised to ensure that the User's input is
not wiped out by recalculation. My personal preference in circumstances
where I would like the User input to be "sticky" is to do a recalculate
only when the contents of the field are deleted. This allows a user who
has messed-up the opportunity to regain the "default" auto-entered
value.

In article <1131625473.680298.142760 (AT) g49g2000cwa (DOT) googlegroups.com>,
dan (AT) owlsnet (DOT) co.uk says...
My concern was that the user wanted a solution going forwards, and he
was thinking of using replace to "brute force it retroactively" every
few weeks to fix the 'recently created' records.

I may have misunderstood, and like i said in my previous post, if he
just wants to fix some existing data, then the solution you suggested
was best.

I agree, that's frequently the best solution. However, there are some
very useful things that can be done with self-referencing auto-enters
with that box -unchecked-.

For example, you could have a phone number box, with a self-referencing
autoenter that will parse it and format it.

So the user can enter 5551234, 555.1234, 555-1234, 4215551234, etc etc
and as soon as they tab out of the field, it automatically
'recalculates' itself to : (421) 555-1234 ... or whatever. If they don't
enter 7 or 10 digits, the autoenter doesn't mess with it and just
returns it as entered.

We have only just begun to scratch the surface of auto-enter
calculations.The possibilities are endless.

We need to tap into people's ingenuity and we could do with a site that
stores auto-enter calculations, in much the same way as Brian Dunning's
site stores custom functions. Auto-enters also have the advantage of
not needing a developer edition of FMP.

Your phone number example is the sort of thing that is useful and once
seen it is not hard to modify according to country preferences, but you
have to think about it as a possibility first.