Re: NULL's on the Iseries

[Vernon Hamberg <vhamberg@xxxxxxxxxxx>]

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!
> >
> > ;-)
> >
> > Vern
>
>
>
>
>
> ______________________________________________________
> Click here to donate to the Hurricane Katrina relief effort.
> http://store.yahoo.com/redcross-donate3/
> --
> 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.