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