Re: NULL's on the Iseries

["Raul A. Jager W." <raul@xxxxxxxxxx>]

From my limited experience, one important problem with null support is 
in the programmers that learned a few rudiments on DataBase at the time 
before AS had null support, and for those people the concept is a hard 
one to grab.

Vernon Hamberg wrote:

> Hi Marco
>
> Forgive me for using a little humor that is probably not easily 
> understood if you are not a native speaker of English - I did not mean 
> for the expression "violent agreement" to mean anything other than I 
> thought we were saying pretty much the same thing in different ways.
>
> I have also seen things in other platforms that are easier. I have 
> just started to work with SQL Server and see that it has a way to 
> restore a database to a different machine or location very easily. As 
> we have discussed in some posts this year, this is not the easiest 
> thing to do on iSeries.
>
> On the other hand, I had to eliminate duplicates in a table in SQL 
> Server. There is no single function to do this that I, with my limited 
> knowledge, could find. I did not find anything on Google, either, 
> except to rename the table, then run a SELECT that used a technique 
> similar to an output file to a table of the original name, then delete 
> the renamed table. This can also be done in a stored procedure, which 
> would simplify things.
>
> On the iSeries I can do this with STRQMQRY with and output file - I 
> can SELECT over a table and use the same table as the output file, 
> effectively replacing its contents in place. Here a QMQRY must be 
> created, and I believe an SQL stored procedure could also be written 
> to do the same thing as SQL Server.
>
> I was also wondering if NULL attributes are handled the same way in 
> SQL Server or Oracle as they are in embedded SQL. I just looked up 
> something at Microsoft and see that embedded SQL is not just an 
> iSeries idea, it seems to be an SQL standard. Consider the following 
> about "Embedded SQL for C"
>
> > Embedded SQL enables you to store and retrieve null values from a 
> > database by using host indicator variables. Together, a host variable 
> > and its companion indicator variable specify a single SQL value.
>
>
> I also saw that this API is intended for migration from other 
> databases (iSeries, e.g.?) and is going away, and MS encourages people 
> to use things like ADO or ODBC.
>
> I did not find how one tests for the NULL attribute in a column after 
> fetching it in SQL Server.
>
> I do wonder if some of the SQL problems are not coming from SQL 
> itself, not RPG. Maybe?
>
> Thanks
> Vern
>
> At 02:27 AM 9/6/2005, you wrote:
>
> > Hi Vern, please always consider that English is not my language so don't
> > take any special meaning in my posts. It's just hard enough to 
> > explain the
> > matter.
> >
> > But my point is very simple about some aspects of Iseries:
> >
> > We have a fantastic platform but regarding some aspects the support is
> > partial, not complete or... complicated. When I hire a newcomer to this
> > platform I discover, while teaching and comparing with other 
> > platforms, so
> > many aspects of this situation.
> > The Null capacity of any field (an not just on database ones) should be
> > supported in all the languages since is more like a concept than an
> > occasionally need. If I'm missing any function (math, graphic or 
> > whatever) I
> > can [easily] write one or use one from other language but I cannot 
> > mimic a
> > base function as null. Maybe I can but it's a cost that I cannot afford.
> >
> > And honestly I cannot blame the developers team since few years ago 
> > we got
> > the chance to express our opinion about the enhancements we would 
> > like to
> > have and the full null support was in the bottom of the list...
> >
> > Marco
> > --- Vernon Hamberg <vhamberg@xxxxxxxxxxx> wrote:
> >
> > > Marco
> > >
> > > I agree it is not as simple to deal with NULL attributes in SQL as 
> > it is
> > > in
> > > RPG. So I'll go along with you, that it is not supported in a way 
> > that is
> > > as easy to do. It is also harder in C/C++ - you have to deal with a
> > > separate structure there for handling the NULL attribute.
> > >
> > > But does this mean it is almost not supported? A matter of 
> > semantics. I
> > > find that "...almost not...' is an overstatement. You can handle 
> > NULLs in
> > > any of these cases, therefore it IS supported. Easy to do? In RPG 
> > IV, yes.
> > >
> > > In the other situations, no.
> > >
> > > Of course, you CAN do DSPFs & PRTFs in C, but it is not fun. Least 
> > ways,
> > > not so much as in RPG.
> > >
> > > All in all, I think we've violently agreed too long on this topic.
> > >
> > > Long live RPG!
> > >