Now, no matter how many different and complex combinations of $COLUMNS(...)$ + $OBJECT()$ I tried, I was unable to create a working one that would yield the above result. I'm beginning to believe it is impossible. Any help is
appreciated.

Note that table schema is omitted in the declaration. If required, it can be easily added

Wed Dec 20, 2017 4:09 am

gemisigo

Joined: 11 Mar 2010Posts: 1441

Yes, I've tried to use a similar script to create the result, though I didn't bother setting the correct cases. The problem with this approach is that the macros allow selecting columns individually, while the scripted workaround does not.

Wed Dec 20, 2017 10:17 am

SysOpSite Admin

Joined: 26 Nov 2006Posts: 6642

gemisigo wrote:

Yes, I've tried to use a similar script to create the result, though I didn't bother setting the correct cases. The problem with this approach is that the macros allow selecting columns individually, while the scripted workaround does not.

Unfortunately mixing $COLUMNS$ macro with other adjacent macros like $COLUMNS(...)$+$OBJECT(...)$ to generate multi-line script is beyond the capabilities of the macro processing engine. $COLUMNS$ and $ARGUMENTS$ macros support multi-line output driven by the table columns or procedure arguments only while other macros don't, and cannot be used in that manner.

Wed Dec 20, 2017 1:15 pm

gemisigo

Joined: 11 Mar 2010Posts: 1441

Yes, I've run into limitations with each try. I wasn't even able to create

Code:

l_vonal_id vonal_id%TYPE;
l_datum_tol datum_tol%TYPE;

without using '='.

It's funny how

Code:

l_$COLUMNS(vertical)$ = table_name_here.$COLUMNS(vertical)$%TYPE;

works but

Code:

l_$COLUMNS(vertical)$ = $OBJECT$.$COLUMNS(vertical)$%TYPE;

does not.

I have to search&replace the rubbish surrounding '=' and remove the comma from the end of each line except the last one but it still beats entering the whole stuff manually or having to drop lines with unwanted column one by one. Incidentally, isn't there a way to omit those commas or to replace them with AND or OR or whatever is needed in the current situation?

Wed Dec 20, 2017 6:22 pm

SysOpSite Admin

Joined: 26 Nov 2006Posts: 6642

that should be changed to

Code:

"l_"$COLUMNS(vertical)$" = "$OBJECT$.$COLUMNS(vertical)$"%TYPE;"

Anything that contains spaces or non alphanumerics and _ symbols should be enclosed in double quotes. for "l_" I did that only for consistency.

Wed Dec 20, 2017 7:44 pm

gemisigo

Joined: 11 Mar 2010Posts: 1441

Yes, I stand corrected. I added a couple of double quotes here and there when I tried a few things. It turned out that sometimes it helps, sometimes it does not, and sometimes (cases involving '=') it makes no difference

This worked sort of expected. I only had to search&replace "<<table name here;parameter;varchar;=>>" with the table name (I have a script for things like that) and remove the commas from the ends of the lines.

Fri Dec 22, 2017 11:04 am

SysOpSite Admin

Joined: 26 Nov 2006Posts: 6642

Just thinking aloud, if you add $PROMPT$ macro to ask for table name, you can avoid search and replace, as that input can be likely inserted in place of "<<table>>", or perhaps use one of $CURRENT... $ macros to get table name from the script without a need to type it and then the result of that can go in place of "<<table>>"

Fri Dec 22, 2017 11:50 am

gemisigo

Joined: 11 Mar 2010Posts: 1441

These were good ideas. Unfortunately, neither of them worked. If I exclude the double quotes, the result is broken. If I include the quotes the macros between them are not evaluated :(

The conclusion is that excluding '=' is out of the question, none of the candidates without it came anywhere near the desired result. Including '=' implies a mandatory search&replace to remove it. It's clear that omitting double quotes doesn't work either. Their presence also means that no other macros will get their values as they operate sort of an anti-magic field for macros.

To look at the bright side, I can say that I've learnt quite a bit about how these macros work (or don't work).