Hello, I have just came across something that suprised me. I am not sure if it is not supported or a bug:
When you use an unstored calculation of the left side of a relation, Servoy will generate an SQL query that uses that field as if it was a database column, thus yielding an error “unknown column”.
Are unstored calculations (instead of globals) not supported for relations?
I am sorry, I wasn’t that precise: It looks like those relations are not supported in find mode.
Here is what we want to do:
we want to allow the user to mark records of “any kind”, which means whatever table they are in
so we created a table called “marks” that has a PK_data column (primary key of the record) and a table_data (table name of the record) plus the user_id
in order to avoid setting a global for the table name (to fill table_data) we thought it’d be easier to have a calculation in every relevant table that simply delivers its name (return table_name;)
If you search over a relation constructed like this, you’ll get no results. If you use a global instead of that calc, you are fine.
i just made an example for this. And it works greate.
Calc on the leftside (just returning 1) and a field of a table on the right side together with a real dbcolumn->dbcolumn (fk->pk)
yes i have fixed it.
But what do you want to happen?
Because an unstored calculation is purely in mem specific to a column. So yes looking up a relation is possible. But when you search for it then how do you fill in that unstoredvalue? Do you do that by hand? Is that value also set somehow (through ui or in a script?)
because if you don’t set it the unstored calculation is always null. So the relation will not return any values anyhow…
I am not sure I can follow you. In my situation I returned a fix value just like you did in your tests with that 1 (I return a string).
Although I don’t understand your statement I can see a problem if you do not return a constant in an unstored calculation but something record related. Then, I admit, I can’t tell you either what I want to happen.
I guess I’d rather use a global. The idea about the unstored calc just came because there I have something table based (which I needed here) and I don’t have to remember to fill it.
Thanks for investigating!
Patrick
P.S.: What exactly did you fix? Will it work when returning constants? What happens if the calc just returns for example some other column?
But you do agree that finding things over relations based on calcs is a problem? It’s convenient to necessary to use calcs for relations, but nobody will remember that you cannot use those relations in find mode…
unstored calcs in a relation doesn’t have to be a problem purely for that relation to be looked up for a specific record.
And also for finding over it it is also not a big problem, but then you need to set the calc yourself in the find. Because the value needs to come from somewhere. We can’t enable cals in find mode because then everything can go wrong. Because there is no real data in find mode…
What you really want is a literal inside a relation (that you could set directly in a relation) for now you have to use a global for this.