× 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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.