 |
SoftTree Technologies
Technical Support Forums
|
|
Author |
Message |
gemisigo
Joined: 11 Mar 2010 Posts: 2165
|
|
|
|
I'm not sure backward compatibility should be priority if it gets into way
|
|
Mon Oct 17, 2016 10:12 am |
|
 |
gemisigo
Joined: 11 Mar 2010 Posts: 2165
|
|
|
|
There's obviously an improvement there with only a few things still fishy:
$OBJECT(column)$ allows drilling down to columns and selecting them without allowing to select upper levels (schema, table or view, etc.). Good.
$OBJECT(table)$ allows drilling down to column level but does not allow selecting it. Good.
$OBJECT(table, column)$ allows drilling down selecting both at table or column level, but the checkboxes for column level are gone. Not good, but I'm not sure it's relevant.
Combining $COLUMNS$ with $OBJECT$ like in
 |
 |
UPDATE u
SET
"u."$COLUMNS(vertical,updatable,nokeys)$" = "
-- the key column(s) $COLUMNS(vertical,keys)$
FROM
$OBJECT(ins_schema, table, view)$.$OBJECT(ins_object, table, view)$ AS u|
WHERE 1 = 1
AND "AND u."$COLUMNS(vertical,keys)$" = ";
|
works almost as I'd expect it. It returns no_key colums for $COLUMNS(vertical,updatable,nokeys)$ but fails when retrieving $COLUMNS(vertical,keys)$, it complains not finding keys for the table when selecting columns. When selecting at table level, it just plain works.
Perhaps these two ($COLUMN$ and $OBJECT$) should be made disjunct by not allowing to select column in $OBJECT$ and adding options to return schema and object names for the objects of the selected columns. Or melting them into one by adding options of $COLUMN$ to $OBJECT$ (and thus making $COLUMN$ obsolete), and defining valid and invalid combinations states of options. Not an easy task, either of them, I know.
|
|
Mon Oct 17, 2016 10:37 am |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|