Can't put to calculated field - Huh!!!

[Fulltimer]

I was progressing slowly through the development of my web app when suddenly I started getting the below error msg.

"Script Error
Error:Script:record_add_field_value line:127
Can't put to calculated field"

This first occured when I tried to change a field rule that calculated the length of the data in another field. At first my calculation just used :

len(field_name_1) -- this was okay -initially

The problem was this always gave me the same result - a field length of 100.

Then I realized that what I "REALLY" wanted was :

len(alltrim(field_name_1)) - to capture the length of the data INSIDE the field.

Once I did that, I started to get the error msg above. Even changing it BacK To the original doesn't eliviate the error. Seems A5 wants to hold onto something, somewhere and I can't proceed at this point.

Please help, this has got me baffled!!

[Fulltimer]

Re: Can't put to calculated field - Huh!!!

After further careful examination I believe I may have found the real problem of my above mentioned post.

This line:

record_update("law_office","findkey_lawoffice="+quote(tofind),"date_modified ="+ dtoc(date()))

Is causing the problem.

The :: "date_modified ="+ dtoc(date()) is not syntactically correct.
I'm trying to update a date field with obviously date data but I am struggling with putting all this together in a line of code that requires a "STRING".

When I convert Date() to a char - that won't work -obviously, yet I can't use real date data in the function because it's not a string.

I know I'm just a minor step away from my solution but I seem to keep stepping over it.

[Fulltimer]

Re: Can't put to calculated field - Huh!!!

I found my problem.

My date_modified field was indeed a Calculated Field and apparently the record_update function does not like you to try and manually "put" a value in such a field.

This is my assumption because when I replace this statement with a normal char field, the function works. If someone has the definitive answer to this question, please let us "ALL" know.

[cy_uab2007]

Re: Can't put to calculated field - Huh!!!

Due to a recent problem of mine with updating fields I ended thinking about this one.

In my experience thus far, it isn't possible to change or enter calculated fields.

The code below will cause the error:
tbl.change_begin(.t.)
tbl.Calc_Field = "somevalue"
tbl.change_end(.t.)

The same error will occur if I use enter_begin()/enter_end(). However, if I use the .update() method, no errors are thrown...

update.fields = 1
update.field1 = "Calc_Field"
update.expr1 = "somevalue"
tbl.update()

This has worked for me in the past on calculated fields if my memory serves me right (did it by accident). Not at my work computer at the moment so I can't verify 100%. It almost seems like the .update() method completely bypasses all the underlying field rules.

Again, I might be wrong.

[Fulltimer]

Re: Can't put to calculated field - Huh!!!

update.fields = 1
update.field1 = "Calc_Field"
update.expr1 = "somevalue"
tbl.update()

Your above solution would be a wonderful fix if it works. I will need to return to that part of my code when I finish my current assignment.

Thanks-----

[Doug Page]

Re: Can't put to calculated field - Huh!!!

What if you change:

tbl.change_begin(.t.)
tbl.change_end(.t.)

to:

tbl.change_begin(.f.)
tbl.change_end(.f.)

which would tell Alpha not to enforce the field rules?

See <TBL>.CHANGE_BEGIN() in the manual.

[MikeC]

Re: Can't put to calculated field - Huh!!!

Hi All,

I could be wrong but a calculated field is just that--something that is calculated and should not be allowed to be set and do not believe that Alpha will--has nothing to do with field rules except for the fact a field is defined as calculated.

I do not think that tbl.change_begin(.f.) or tbl.enter_begin(.f.) will affect this (and I cannot make it do so at all regarding setting a value). The update operation has the same result for me in that the field cannot be changed.

If others can change a calculated field with any method other than by changing the calculations involved I would like to see it and would love to add it to my "help file" . :)

Regarding the tbl.change_end(.f.) or even tbl.enter_end(.f.)----the logical argument in these functions pertain to whether or not the value is committed or not.

[Fulltimer]

Re: Can't put to calculated field - Huh!!!

Regarding the tbl.change_end(.f.) or even tbl.enter_end(.f.)----the logical argument in these functions pertain to whether or not the value is committed or not.

Here is what I found in the help files concerning this issue.

If Field_Rules_Flag is .T., then UI Level field rules are enforced when the record is changed. If the Field_Rules_Flag is .F., then Alpha Five does not enforce these UI Level field rules.

UI Level field rules are rules such as:

trigger events

capitalization

minimum and maximum values

masks/templates

lookup fill-ins

Engine Level rules, such as auto-increment values are always enforced.



Tom

[cy_uab2007]

Re: Can't put to calculated field - Huh!!!

I still haven't had a chance to go back and do a thorough check into what happened when I used update(). I can verify that setting the field rule flag to false does not stop the calculate from triggering. That was one of the first things I tried when I got the error Fulltimer had since I didn't quite understand what was causing it initially.

For those wondering about update() and how I came to my conlcusion, here's the details of how I ran into it.

I set a field in a table to calculate based in part on a lookup from another table. I later forgot about it being calculated and created some code that did an update() on the calculated field when certain values were changed in the lookup table. The update completed with no errors and the changes were visible and correct. Unfortunately, this meant that it took me a bit longer to find an issue with lookup() in a calculated field expression. The calculated field would go back to the old value when I committed a change.

I honestly don't think update() should be working like that, so I either came to the wrong conclusion or it's a bug of some kind.

[MikeC]

Re: Can't put to calculated field - Huh!!!

Tom,

And what you wrote goes right along with what I said, right?

The logical value in tbl.change/enter_begin(.T.) is the field rules flag.

The logical value in tbl.change/enter_end(.T.) is the commit flag.


You will notice also that nowhere is it said that the UI Level field rules include changing the field to something else other than calculated (although they do qualify the list as "some")--and if it is different I apologize, but I don't think a user should be able to change a calculated fields value---if it were possible it would cause a disparity between the "new" value and the one the field rules calculation creates. A Default value would be the one in which to use in this case IMHO.

[cy_uab2007]

Re: Can't put to calculated field - Huh!!!

Just verified update() is screwy. Used the stuff I originally had problems with.

Test steps were:
1. Change a field to calculated.

2. Edit my XBasic that was performing update() to write a completely incorrect string ('whatever you want') to that field.

3. Run the XBasic and the change shows.

4. Change/commit one of the records (change didn't directly effect the calculated field) and it returns to the "correct" calculated value.

Picture of the junk values and the reset calculated value attached. I personally think this qualifies as a strong bug and shouldn't be relied on as a correct way to update a field. Chances are it will be fixed and then you'll be left with a "WTH? It was working yesterday!" problem.

Side question.. what's the SOP for bug submittal?

[Al Buchholz]

Re: Can't put to calculated field - Huh!!!

SOP for a bug report is on the A5 menu system.

help - report bug

It'll start an email where you should describe the problem and detail an attached example.

Before you submit this bug, post the detail and an example here and we can test it before the A5 dev crew has to work on it.

[cy_uab2007]

Re: Can't put to calculated field - Huh!!!

Al,

Any suggestion on how much more I should provide beyond the basics I've already given? I don't want to submit my whole project, since that'd just hurt people's eyes. There's only so much rainbow-puke-creating-bad-code on your screen that any one person can take. :D

Thanks,
Andrew

[Al Buchholz]

Re: Can't put to calculated field - Huh!!!

Andrew

When I submit a bug report, I build a new directory, a new database, make a simple table(s/set) with only the fields and code needed to show the problem.

Then I zip the directory and attach it to the bug report.

Then I'm verifying that the problem exists on it's own and isn't a part of a combination effect of other issues.

It doesn't take as long to do, as it did to write this message....

ps - It also saves an embarrassing moment when Alpha replies that it was my coding that caused the problem. This happens less now than it has before I started this procedure. :o

I've discovered many new techniques from this..

[cy_uab2007]

Re: Can't put to calculated field - Huh!!!

Ok, been awhile but let's dig this up again since I left it sorta hanging.

I looked into help files about the <tbl>.update() function and others like it and it seems like the ability to ignore field rules such as calculation is deliberate. I found that <tbl>.post() and a few other functions which are similar in design, and functions such as these skip calculation and other such rules (field recalculation must be manually triggered after running one of these high level functions). I'll admit that being able to write to a calc'd field seems like a rather weak design style considering that it isn't allowed through the low level methods, but the documentation does cover it [sort of].

As far as this being a bug goes, I think I'm going to drop that idea. I may submit the issue as a requested change, but who knows. If I find the time, I'll try to post a simple example for those who would like to know how this can effect your data.

Happy Holidays!