[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

2670.0. "SQL parameters indicators and case sensitivity" by AEO780::BONNIER (Jean-Luc ... EIC/T&N Annecy France) Thu Apr 02 1992 05:45

Hi Sam,

We are working on DECmcc VMS T1.2.4 and the Exporter FM.

After the Exporter has collected data from the network, we use C programs 
with dynamic SQL to analyze the data from the RDB database.

We have some trouble with the recovery of the data ; specialy to count
successful/unsuccessful polls.

So far the C programs do something like:

       EXEC SQL   FETCH :cur INTO :state:state_ind,
                                  :sstate:sstate_ind,
                                  :dat;

that means that we check 'indicator parameters' (here 'state_ind') for a negative
value to determine whether the value of the retrieved column (here 'state') 
is NULL.

Instead of using these 'indicator parameters', is it equivalent to test
the MCC_EXPORT_POLL_STATUS column ? (=1 if data available, =0 otherwise).
Is this column valid for ANY Rdb table ?

We have also some trouble with the uppercase/lowercase formats of the
global entities/sub-entities instances retrieval. Is there a rule for this 
format ?
Do we have to SQL SELECT from RDB tables always with values in the SAME CASE
as registered ?

Thx again for your help.
Jean-Luc
T.RTitleUserPersonal
Name		DateLines
2670.1use LIKE ... IGNORE CASEAEO780::BONNIERJean-Luc ... EIC/T&N Annecy FranceThu Apr 02 1992 05:4764
From:	TOOK::SHMUYLOVICH  "Samuil Shmuylovich LKG2-2/T2 DTN: 226-5351"  1-APR-1992 18:42:22.53
To:	AEO780::BONNIER
CC:	SHMUYLOVICH
Subj:	RE: DECmcc exporter FM questions


	Jean-Luc,


>Instead of using these 'indicator parameters', is it equivalent to test
>the MCC_EXPORT_POLL_STATUS column ? (=1 if data available, =0 otherwise).
>Is this column valid for ANY Rdb table ?

 The MCC_EXPORT_POLL_STATUS column is valid for any Rdb table, created by
 the Exporter FM V1.2.
 The value of "1" does not guarantee that all attributes have been received 
 and written in the RDB table; it means than this particular poll was 
 successful ( Show ALL Identifiers). 
 So it's possible to have "1" in this column and NULL for same of the 
 attribute columns.

>We have also some trouble with the uppercase/lowercase formats of the
>global entities/sub-entities instances retrieval. Is there a rule for this 
>format ?

 Exporter does not change the case for any string data. In other words it
 writes string values into the RDB in the same case as they have been 
 returned by Show command.

>Do we have to SQL SELECT from RDB tables always with values in the SAME CASE
>as registered ?

 Most SQL conditional operators are case sensitive, for example:

 SQL> select node4,name from mcc_node4 where name = "rudone";
 0 rows selected
 SQL> select node4,name from mcc_node4 where name = "RUDONE";
  NODE4     NAME
  4.773     RUDONE
  4.773     RUDONE
  4.773     RUDONE
 3 rows selected
 SQL>

 To ignore the distinction between uppercase and lowercase letters, you can 
 use LIKE and NOT LIKE conditional operators with IGNORE CASE clause,for 
 example:

 SQL> select node4,name from mcc_node4 where name like "rudone%" ignore case;
  NODE4     NAME
  4.773     RUDONE
  4.773     RUDONE
  4.773     RUDONE
 3 rows selected
  SQL>

 Please, note that LIKE and NOT LIKE operators require that you account
 for trailing space characters. Or you can use a wildcard "%" ( see above
 example).

 The CONTAINING and NOT CONTAINING conditional operators are not case sensitive.


    Regards, Sam