Re: Trigger question - Null Fields

John,

>Is  SQL the only way we have to create a field as being null capable in the
>first place or is there a DDS equivalent?  Can you change an existing field
>to or from being null capable?

You can create them via DDS you would use the ALWNULL(?) keyword.
You may be able to use the CHGPF after changing the DDS, I haven't tried 
that myself.   Remember a field can't be null capable if it is a UNIQUE
keyfield.

>Also, I asked on an earlier post which no one responded to, whether anyone
>had any experience using the new user defined field objects.  Do you know
of
>anyone working with them?  They are very interesting to me, since if  I
>understand it correctly, we could perhaps move some of the trigger
>record-level editing on down to the actual field level.

Well there are two things UDT's and UDF's

User Defined Types(UDT) - allow you to define your own data type.
Classic example is like US_Dollars for example.  You would not 
inadvertently be able to add this field to another plain numeric.  
Remember Native I/O(RPG Read/Write/Update) is not allowed on
a table(file) with UDT's.   It's SQL or nothing. 

User Defined Functions(UDF) - allows you to create your own SQL function.
Something like a RPG procedure( ie   EVAL  NAME = DAYOFWEEK(DATE) )
There are 3 flavors;  External, Sourced, and SQL.    For the Sourced & SQL
types
you must have SQL and the C compiler on your machine. 

Both of these are need V4R4.   I don't see you using them in a typical RPG
system.
I will signon to my V4R4 box today and give you more info if you  would
like.

They are so new(how many people are on V4R4 ?) that not many people have
real life experience with them.   I will be experimenting with them soon on
my
V4R4 170.  I'll give you feedback if you'd like.

>Also, apparently
>this is what the rest of the SQL world uses instead of field reference
>files? Is that correct?  If so, how would you control and/or catalog a
large
>number of them.  Create a whole separate library for them maybe?  Also, I
>assume you have to have the C compiler to write code for them too?

Well the Field Reference thing is still not  SQL friendly.    I still
believe 
the benefits of a well structured Field Reference with the refer process
is head and shoulders above anything in SQL.   The ability of having
just ONE definition of (say)  Invoice number, Order Number system wide
can't be done in SQL.    I ran a simple listing of a DSPFFD outfile of our 
files and was able to produce a report of every DATE(numeric ones) that
we had on our box.   Every PF, LF, PRTF, DSPF, and Template file(ex. DS)
that
used the old 6,0 date field when we did our Y2K project.  Then using
DSPPGMREF
outfile listed every program that used those files.

As for the SQL catalog,   do a WRKOBJ   QAD* and see what you see.
When you create a SQL Collection (an OS/400 library plus other stuff)
you will automatically get views of those tables for files in that
Collection(library).

I don't know if I answered the questions or not but ,   there you go.

John Carr
SQL classes via    www.400school.com
PowerTech


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---