Re: NULL's on the Iseries

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!
>