NULLS & ACE

Hello to all. This is my first posting to this group so... a little message for Obnoxio (if you're reading) "Please be nice". I have already gleaned a great deal of useful info from this group and thought it was about time I took the plunge with a specific problem of my own. FYI. I am a very old-fashioned user, (Informix-SQL vers 1.10 circa 1984 running under Xenix), recently ported across to IDS 7.3 with Informix-SQL 7.3 under Linux. My problem follows on from the thread "NULL vs NOT NULL". Never having had the luxury of NULLs on my original system I had to decide how best to utilise them. I settled on using NULL wherever poss. and disallowing blank entries on all char fields. They seemed to serve no useful purpose on our very small system and besides it was as good as any tactic I could think of. I hoped it would standardise the creation of new 'forms' & 'reports'. i.e. you know you only have to check for NULL and not empty string or indeed a string full or partially full of spaces! Applying my 'rule' to input; not a problem. However, when I try and convert the ACE reports I find that unlike PERFORM there is no NULL assignment value. e.g. LET foobar = NULL. ACE initialises a char(n) variable as a 'n' space filled string. On my old system I always reinitialised variables to empty string and now want to set them to NULL to keep them in line with my 'always use NULL' rule. I tried to write a simple c function to return NULL with 'strreturn'. Unfortunately, 'strreturn' doesn't return NULL terminated strings only strings of a specific length. What is the length of NULL? 0? In which case 'strreturn' will return nothing! I have RTFMed and trawled the web but can find nothing about this problem. Am I missing something or is my tactic basically flawed?? Any help, guidance, therapy, etc.. greatly received. Many thanks, Daryl. 8O)

IMS the ACE statement is the same as the 4GL statement: INITIALIZE foobar TO NULL Art S. Kagel Daryl Craig-Elliot wrote: > > Hello to all. > > This is my first posting to this group so... a little message for > Obnoxio (if you're reading) "Please be nice". > > I have already gleaned a great deal of useful info from this group and > thought it was about time I took the > plunge with a specific problem of my own. > > FYI. I am a very old-fashioned user, (Informix-SQL vers 1.10 circa 1984 > running under Xenix), recently > ported across to IDS 7.3 with Informix-SQL 7.3 under Linux. > > My problem follows on from the thread "NULL vs NOT NULL". > > Never having had the luxury of NULLs on my original system I had to > decide how best to utilise them. > I settled on using NULL wherever poss. and disallowing blank entries on > all char fields. They seemed > to serve no useful purpose on our very small system and besides it was > as good as any tactic I could > think of. I hoped it would standardise the creation of new 'forms' & > 'reports'. i.e. you know you only > have to check for NULL and not empty string or indeed a string full or > partially full of spaces! > > Applying my 'rule' to input; not a problem. However, when I try and > convert the ACE reports I find that > unlike PERFORM there is no NULL assignment value. e.g. LET foobar = > NULL. ACE initialises a char(n) > variable as a 'n' space filled string. On my old system I always > reinitialised variables to empty string and > now want to set them to NULL to keep them in line with my 'always use > NULL' rule. I tried to write a simple > c function to return NULL with 'strreturn'. Unfortunately, 'strreturn' > doesn't return NULL terminated strings > only strings of a specific length. What is the length of NULL? 0? In > which case 'strreturn' will return nothing! > > I have RTFMed and trawled the web but can find nothing about this > problem. Am I missing something or is > my tactic basically flawed?? > > Any help, guidance, therapy, etc.. greatly received. > > Many thanks, > > Daryl. 8O)

Daryl Craig-Elliot wrote: > This is my first posting to this group so... a little message for > Obnoxio (if you're reading) "Please be nice". > > I have already gleaned a great deal of useful info from this group and > thought it was about time I took the plunge with a specific problem of my own. > > FYI. I am a very old-fashioned user, (Informix-SQL vers 1.10 circa 1984 > running under Xenix), recently > ported across to IDS 7.3 with Informix-SQL 7.3 under Linux. 1985, I think; or 1986. ISQL 1.10 did not have any null support in it; ISQL 2.00 and the concurrently released I4GL 1.00 added that as one of the big new features! > My problem follows on from the thread "NULL vs NOT NULL". > > Never having had the luxury of NULLs on my original system I had to > decide how best to utilise them. C J Date would say "Don't"; I'd agree. > I settled on using NULL wherever poss. and disallowing blank entries on > all char fields. They seemed > to serve no useful purpose on our very small system and besides it was > as good as any tactic I could > think of. I hoped it would standardise the creation of new 'forms' & > 'reports'. i.e. you know you only > have to check for NULL and not empty string or indeed a string full or > partially full of spaces! Distinguishing between a single space and many spaces is essentially impossible. And if a field is left looking like it is all blank, that is interpreted as NULL by ISQL. > Applying my 'rule' to input; not a problem. OK. > However, when I try and > convert the ACE reports I find that > unlike PERFORM there is no NULL assignment value. e.g. LET foobar = > NULL. ACE initialises a char(n) > variable as a 'n' space filled string. Funny; I can compile: DATABASE stores END DEFINE VARIABLE i CHAR(30) END SELECT tabname, tabid FROM systables ENDFORMAT ON EVERY ROW LET i = NULL PRINT i, tabid, tabname END However, I agree that I cannot run it -- it comes up with error -9004. I think that is a bug. I'm also astonished no-one has come across it before. I changed the ON EVERY ROW clause to: LET i = '' IF i IS NULL THEN PRINT "i is NULL", tabid, tabname ELSE PRINT "i is blank", tabid, tabname and this not only compiles and runs but also produces "i is NULL" in the output. This simple workaround is probably why no-one has reported the bug. And it also leads to confusion because in an SQL statement (eg SELECT), the empty string is not a null, whereas in ACE (and in I4GL) it is a null string. > On my old system I always > reinitialised variables to empty string and > now want to set them to NULL to keep them in line with my 'always use > NULL' rule. I tried to write a simple > c function to return NULL with 'strreturn'. Unfortunately, 'strreturn' > doesn't return NULL terminated strings > only strings of a specific length. What is the length of NULL? 0? In > which case 'strreturn' will return nothing! Building a custom runner is not something I'd do to handle this. > I have RTFMed and trawled the web but can find nothing about this > problem. Am I missing something or is > my tactic basically flawed?? > > Any help, guidance, therapy, etc.. greatly received. Art Kagel suggested using INITIALIZE; that's not an ACE operation. -- Yours, Jonathan Leffler (Jonathan.Leffler@Informix.com) #include <disclaimer.h> Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN "I don't suffer from insanity; I enjoy every minute of it!"

"Art S. Kagel" <kagel@bloomberg.net> wrote in message news:39883FD0.960451AD@bloomberg.net... > IMS the ACE statement is the same as the 4GL statement: Yes, but I suspect Daryl is using PERFORM to write directly to his database. > > INITIALIZE foobar TO NULL In some i4gl's, if foobar is a string, this will still be space padded - certainly the version I use Better to test length( foobar), This will be 0 if foobar is either NULL, or space padded > > Art S. Kagel > > Daryl Craig-Elliot wrote: > > > > Hello to all. > > > > This is my first posting to this group so... a little message for > > Obnoxio (if you're reading) "Please be nice". > > > > I have already gleaned a great deal of useful info from this group and > > thought it was about time I took the > > plunge with a specific problem of my own. > > > > FYI. I am a very old-fashioned user, (Informix-SQL vers 1.10 circa 1984 > > running under Xenix), recently > > ported across to IDS 7.3 with Informix-SQL 7.3 under Linux. > > > > My problem follows on from the thread "NULL vs NOT NULL". > > > > Never having had the luxury of NULLs on my original system I had to > > decide how best to utilise them. > > I settled on using NULL wherever poss. and disallowing blank entries on > > all char fields. They seemed > > to serve no useful purpose on our very small system and besides it was > > as good as any tactic I could > > think of. I hoped it would standardise the creation of new 'forms' & > > 'reports'. i.e. you know you only > > have to check for NULL and not empty string or indeed a string full or > > partially full of spaces! > > > > Applying my 'rule' to input; not a problem. However, when I try and > > convert the ACE reports I find that > > unlike PERFORM there is no NULL assignment value. e.g. LET foobar = > > NULL. ACE initialises a char(n) > > variable as a 'n' space filled string. On my old system I always > > reinitialised variables to empty string and > > now want to set them to NULL to keep them in line with my 'always use > > NULL' rule. I tried to write a simple > > c function to return NULL with 'strreturn'. Unfortunately, 'strreturn' > > doesn't return NULL terminated strings > > only strings of a specific length. What is the length of NULL? 0? In > > which case 'strreturn' will return nothing! > > > > I have RTFMed and trawled the web but can find nothing about this > > problem. Am I missing something or is > > my tactic basically flawed?? My copy of the manual (i4gl v 4.0) is (probably) older than Daryl's - and I don't think it's there either. > > > > Any help, guidance, therapy, etc.. greatly received. > > > > Many thanks, > > > > Daryl. 8O)

Jonathan Leffler wrote: > Daryl Craig-Elliot wrote: > > This is my first posting to this group so... a little message for > > Obnoxio (if you're reading) "Please be nice". > > > > I have already gleaned a great deal of useful info from this group and > > thought it was about time I took the plunge with a specific problem of my own. > > > > FYI. I am a very old-fashioned user, (Informix-SQL vers 1.10 circa 1984 > > running under Xenix), recently > > ported across to IDS 7.3 with Informix-SQL 7.3 under Linux. > > 1985, I think; or 1986. ISQL 1.10 did not have any null support in it; > ISQL 2.00 > and the concurrently released I4GL 1.00 added that as one of the big new > features! > > > My problem follows on from the thread "NULL vs NOT NULL". > > > > Never having had the luxury of NULLs on my original system I had to > > decide how best to utilise them. > > C J Date would say "Don't"; I'd agree. > So... is my 'tactic' basically flawed or is it just personal preference? > > > I settled on using NULL wherever poss. and disallowing blank entries on > > all char fields. They seemed > > to serve no useful purpose on our very small system and besides it was > > as good as any tactic I could > > think of. I hoped it would standardise the creation of new 'forms' & > > 'reports'. i.e. you know you only > > have to check for NULL and not empty string or indeed a string full or > > partially full of spaces! > > Distinguishing between a single space and many spaces is essentially > impossible. And if a field is left looking like it is all blank, that > is interpreted as NULL by ISQL. > > > Applying my 'rule' to input; not a problem. > > OK. > > > However, when I try and > > convert the ACE reports I find that > > unlike PERFORM there is no NULL assignment value. e.g. LET foobar = > > NULL. ACE initialises a char(n) > > variable as a 'n' space filled string. > > Funny; I can compile: > > DATABASE stores END > DEFINE VARIABLE i CHAR(30) END > SELECT tabname, tabid FROM systables END> FORMAT > ON EVERY ROW > LET i = NULL > PRINT i, tabid, tabname > END > > However, I agree that I cannot run it -- it comes up with error -9004. > I think that is a bug. I'm also astonished no-one has come across it > before. > > I changed the ON EVERY ROW clause to: > LET i = '' > IF i IS NULL THEN > PRINT "i is NULL", tabid, tabname > ELSE > PRINT "i is blank", tabid, tabname > > and this not only compiles and runs but also produces "i is NULL" in the > output. This simple workaround is probably why no-one has reported the > bug. And it also leads to confusion because in an SQL statement (eg > SELECT), the empty string is not a null, whereas in ACE (and in I4GL) it > is a null string. > That did the trick!!! I thought I had check this but obviously not! Many thanks for the info. Problem solved. > > > On my old system I always > > reinitialised variables to empty string and > > now want to set them to NULL to keep them in line with my 'always use > > NULL' rule. I tried to write a simple > > c function to return NULL with 'strreturn'. Unfortunately, 'strreturn' > > doesn't return NULL terminated strings > > only strings of a specific length. What is the length of NULL? 0? In > > which case 'strreturn' will return nothing! > > Building a custom runner is not something I'd do to handle this. > > > I have RTFMed and trawled the web but can find nothing about this > > problem. Am I missing something or is > > my tactic basically flawed?? > > > > Any help, guidance, therapy, etc.. greatly received. > > Art Kagel suggested using INITIALIZE; that's not an ACE operation. > > -- > Yours, > Jonathan Leffler (Jonathan.Leffler@Informix.com) #include <disclaimer.h> > Guardian of DBD::Informix v1.00.PC1 -- http://www.perl.com/CPAN > "I don't suffer from insanity; I enjoy every minute of it!"

"Art S. Kagel" wrote: > IMS the ACE statement is the same as the 4GL statement: > > INITIALIZE foobar TO NULL > > Art S. Kagel > I no nothing of this 4GL of what you speak. See I told you I was old-fashioned. By the way, what is IMS? Thanks for you attention. Daryl. > > Daryl Craig-Elliot wrote: > > > > Hello to all. > > > > This is my first posting to this group so... a little message for > > Obnoxio (if you're reading) "Please be nice". > > > > I have already gleaned a great deal of useful info from this group and > > thought it was about time I took the > > plunge with a specific problem of my own. > > > > FYI. I am a very old-fashioned user, (Informix-SQL vers 1.10 circa 1984 > > running under Xenix), recently > > ported across to IDS 7.3 with Informix-SQL 7.3 under Linux. > > > > My problem follows on from the thread "NULL vs NOT NULL". > > > > Never having had the luxury of NULLs on my original system I had to > > decide how best to utilise them. > > I settled on using NULL wherever poss. and disallowing blank entries on > > all char fields. They seemed > > to serve no useful purpose on our very small system and besides it was > > as good as any tactic I could > > think of. I hoped it would standardise the creation of new 'forms' & > > 'reports'. i.e. you know you only > > have to check for NULL and not empty string or indeed a string full or > > partially full of spaces! > > > > Applying my 'rule' to input; not a problem. However, when I try and > > convert the ACE reports I find that > > unlike PERFORM there is no NULL assignment value. e.g. LET foobar = > > NULL. ACE initialises a char(n) > > variable as a 'n' space filled string. On my old system I always > > reinitialised variables to empty string and > > now want to set them to NULL to keep them in line with my 'always use > > NULL' rule. I tried to write a simple > > c function to return NULL with 'strreturn'. Unfortunately, 'strreturn' > > doesn't return NULL terminated strings > > only strings of a specific length. What is the length of NULL? 0? In > > which case 'strreturn' will return nothing! > > > > I have RTFMed and trawled the web but can find nothing about this > > problem. Am I missing something or is > > my tactic basically flawed?? > > > > Any help, guidance, therapy, etc.. greatly received. > > > > Many thanks, > > > > Daryl. 8O)

Robert Stuart wrote: > "Art S. Kagel" <kagel@bloomberg.net> wrote in message > news:39883FD0.960451AD@bloomberg.net... > > IMS the ACE statement is the same as the 4GL statement: > > Yes, but I suspect Daryl is using PERFORM to write directly to his database. > Indeed I am. Sorry for not stating this explicitly. It's easy to forget that not everyone is using the same applications as us. My humble apologies. Problem now solved. See Jonathan's reply. Many thanks, Daryl. > > > > > INITIALIZE foobar TO NULL > > In some i4gl's, if foobar is a string, this will still be space padded - > certainly the version I use > > Better to test length( foobar), > This will be 0 if foobar is either NULL, or space padded > > > > > Art S. Kagel > > > > Daryl Craig-Elliot wrote: > > > > > > Hello to all. > > > > > > This is my first posting to this group so... a little message for > > > Obnoxio (if you're reading) "Please be nice". > > > > > > I have already gleaned a great deal of useful info from this group and > > > thought it was about time I took the > > > plunge with a specific problem of my own. > > > > > > FYI. I am a very old-fashioned user, (Informix-SQL vers 1.10 circa 1984 > > > running under Xenix), recently > > > ported across to IDS 7.3 with Informix-SQL 7.3 under Linux. > > > > > > My problem follows on from the thread "NULL vs NOT NULL". > > > > > > Never having had the luxury of NULLs on my original system I had to > > > decide how best to utilise them. > > > I settled on using NULL wherever poss. and disallowing blank entries on > > > all char fields. They seemed > > > to serve no useful purpose on our very small system and besides it was > > > as good as any tactic I could > > > think of. I hoped it would standardise the creation of new 'forms' & > > > 'reports'. i.e. you know you only > > > have to check for NULL and not empty string or indeed a string full or > > > partially full of spaces! > > > > > > Applying my 'rule' to input; not a problem. However, when I try and > > > convert the ACE reports I find that > > > unlike PERFORM there is no NULL assignment value. e.g. LET foobar = > > > NULL. ACE initialises a char(n) > > > variable as a 'n' space filled string. On my old system I always > > > reinitialised variables to empty string and > > > now want to set them to NULL to keep them in line with my 'always use > > > NULL' rule. I tried to write a simple > > > c function to return NULL with 'strreturn'. Unfortunately, 'strreturn' > > > doesn't return NULL terminated strings > > > only strings of a specific length. What is the length of NULL? 0? In > > > which case 'strreturn' will return nothing! > > > > > > I have RTFMed and trawled the web but can find nothing about this > > > problem. Am I missing something or is > > > my tactic basically flawed?? > > My copy of the manual (i4gl v 4.0) is (probably) older than Daryl's - and I > don't think it's there either. > > > > > > > Any help, guidance, therapy, etc.. greatly received. > > > > > > Many thanks, > > > > > > Daryl. 8O)