×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 24 Jun 2013 02:01, Gad Miron wrote:
I think I'll wait with the DCR ... (-:
Just set the column to the DEFAULT on the UPDATE, if you want the
column updated to the default value which was defined as the USER
special register. I am unsure of what is the concern noted by Rob,
because the User Special Register is AFaIK the /current user/ of the
job, which is generally the desirable value from the perspective of the
typical application. And if another special register is desirable to
effect for an UPDATE [e.g. CLIENT USERID or SYSTEM_USER], then an
application can set the column directly to that special register or to a
variable name that was previously set to the value of that special register.
How about "With default User" ?
It does not work in my tests.
<sarcasm> Wow! Having so explicitly described the difficulty that
was encountered, receipt of valuable assistance from numerous replies
should be expected to provide a quick resolution to whatever is the
problem. </sarcasm>
Should we presume that the column definition on the CREATE TABLE was
incompatible with the chosen Special Register as DEFAULT? That perhaps
the default-clause specifying USER was had been declared as less than
CHAR(18) [or VARCHAR(18) or some other compatible\cast-able] data type,
for which SQL0574 "DEFAULT, identity, or sequence attribute is not
valid." was the error, for which the CREATE TABLE "does not work"? And
that message presumably had further clarified that "If the DEFAULT value
is defined as the value of the USER special register, the column must be
defined as a CHAR or VARCHAR and the length attribute must be greater
than or equal to 18."? If not, then perhaps "does not work" can be
clarified with a script and the errors effected.?
Rob on Fri, 21 Jun 2013 07:58:38 -0400 wrote:
There is not a row change user capability at this time. Upon
initial thought one would think this would be easy and you should
submit a DCR and/or a COMMON requirement to get IBM on this. You
still may want to. But consider this; what about all those jobs
that run under one profile but service another? <<SNIP>>
Of course an UPDATE [and optionally also an INSERT] TRIGGER could do
for any column that should always be assigned the value of the current
USER, effectively the same thing that the database does for a ROW CHANGE
TIMESTAMP. That is, irrespective of what is requested to be inserted or
updated for that column, the TRIGGER(s) can override\set the more
desirable value. And of course, the minimal declaration of 18
characters for DEFAULT USER is also easily removed as a requirement.
midrange.com
