> Carol,
 > 
 > > Definately 2 tables needed to handle it at minimum. Pkey will be
 > > the issue to make it easier so you'd add to a full nodenumber
 > > (4d likely bet).
 > 
 >    That I'll be using... (zone:net/node.point, though I'm not really using t
 > point field for anything yet...)

The problem with SQL is that folks do not list in the same order and SQL is
very 'driven' by that.

The primary part is in order, but once you get after the 'phone field' all
bets are off.

 > >  Add a possible populated 5d {at}netname to the initial set and you
 > > have a generatable key set with the + that covers more than fidonet.
 > 
 >    That's being put in to the nodelist table, but I'm not certain how I'll u
 > it for the DNS table(s)...
 > 
 > 
 > > substrib(15,4) sounds right to hndle the INA
 > 
 >    Not yet certain how I'll be doing that, but more likely to use Perl rathe
 > than SQL, because I'd likely be needing to process more than just the one
 > flag...  (get the set of flags, process them as an array or hash...)
 > 
 > 
 > > but you'd need to NVL or coalesce for null values?
 > 
 >    Not sure about that, but there shouldn't be any null values in the table;
 > all fields are defined as 'NOT NULL" and have a default set...

The order though is hampering me. I'm investigating coalesce for uses but it's
 one I have not used before.  The alternative is a second table then a huge
NVL driven subscript set to move the various entries 'where they should be'
based on final run.

Having fun and wanting to do it with pure SQL just for the learning level.

BTW, the battlenet nodelist is pretty small and makes a decent testing
ground.  Not but about 25 nodes in there if you want a sample one to use.
     
Email or netmail me for a copy. email is cshenk1{at}cox.net
           xxcarol


--- SBBSecho 2.11-Win32