Question about relations

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?

Thanks
Patrick

yes they are supported, it works fine for us, can you post a small sample solution which shows the problem?

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.

Patrick

Is there any info on this? Is this not supported or a bug? Can we use calculations for this or better not?

Thanks
Patrick

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)

Have you tried to search for records over that relation? I can make a demo of this problem, it’s reproducable here…

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…

Hello Johan,

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. :lol:

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?

calculation don’t return anything at the moment in find mode.
So even a fixed value will not be returned.

That’s a clear answer :lol:

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.

How perfectly you guys understand our needs :lol: :

What you really want is a literal inside a relation (that you could set directly in a relation)

What do you mean by “setting a calc myself”? How can I do that?

javascript:

calclProv = ‘XX’;

or make the field in the editor editable.

Then that value is used as a search value.

jcompagner:
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.

:D Yes exactly! It would be a great Christmas present from Servoy team for us developpers.

BTW, merry Christmas and Happy New Year!

we put it on our list.