Rick;
DBU will "auto populate" a timestamp field with the current time, thus overriding the default in your DDL.
You are getting no true default values because DBU is writing all of the fields.
Duane Christen
--
Duane Christen
Senior Software Engineer
(319) 790-7162
Duane.Christen@xxxxxxxxxx
Visit PAETEC.COM
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rick.Chevalier@xxxxxxxxxxxxxxx
Sent: Friday, May 15, 2009 1:52 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: Default user ID in SQL table
Rob,
The records are being added using DBU. What confuses me is that 'with default CURRENT_TIMESTAMP' gives me the current timestamp when adding but 'with default USER' does not.
I used SQL to insert the records to get the defaults but I was expecting the default user regardless of how the record was added.
Rick
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Friday, May 15, 2009 1:32 PM
To: Midrange Systems Technical Discussion
Subject: Re: Default user ID in SQL table
How are you doing your adds outside of SQL?
For example, if you are using the file in RPG with an F spec and you do a WRITE then forcing a value in those fields. You are not telling it to set it to default values. The trick there is to either use sql to insert data or use a LF that omits the fields that you want to leave to system defaults. With 6.1 you can now use DDL to define such a file.
As an example, you will get two totally different things from this:
INSERT INTO rob.errsvrty (error_severity, description) VALUES(1,'duh');
INSERT INTO rob.errsvrty (error_severity,
description,add_user,add_timestamp,update_user,update_timestamp)
VALUES(2,'louie','RALPH',current timestamp - 5 minutes,'MALPH',CURRENT TIMESTAMP - 10 minutes);
select * from rob.errsvrty;
ERROR_SEVERITY DESCRIPTION ADD_USER ADD_TIMESTAMP UPDATE_USER
...
1 duh ROB
2009-05-15-14.19.37.572656 ROB ...
2 louie RALPH
2009-05-15-14.16.44.816310 MALPH ...
In the second I am forcing values in there and not allowing defaults to be used.
Let me try upddta...
Well, upddta took the values from the screen. Blanks and '0001-01-01-00.00.00.000000 are not null, they are screen values. You told it to not allow null. There are some files that I've used upddta on and specified allow null and it seemed to respect that. But you don't want nulls, you want those default values. Well, keep users out of UPDDTA. :-) Actually, control the WRITE. Again, either use sql and specify the fields to be inserted, or use an appropriate LF with RPG.
Now, your update will still not work the way you are hoping until you get to 6.1 and use the new functionality with timestamp. Personally, I feel you'd be better served by using a trigger. That way you have total control over UPDDTA, SQL, RPG, God knows what...
Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
Privileged and Confidential. This e-mail, and any attachments there to, is intended only for use by the addressee(s) named herein and may contain privileged or confidential information. If you have received this e-mail in error, please notify me immediately by a return e-mail and delete this e-mail. You are hereby notified that any dissemination, distribution or copying of this e-mail and/or any attachments thereto, is strictly prohibited.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
