Re: PRO*C FETCH, is this expected behavior?

In article <gsrhpqbtssmith_at_netcom.com>, tssmith_at_netcom.com (Tim Smith) writes:

|>
|> I missed the original posting that Philip is responding to, but be
|> aware that in the version 1.4 (available very soon) Pro*C and
|> Pro*Pascal precompilers, you have a new command EXEC SQL TYPE ...
|> This allows you to set a defined type to correspond to any ORACLE
|> external datatype, such as STRING (datatype code 5). So in Pro*C you
|> could do:
|>
|> typedef char asciz;
|>
|> EXEC SQL BEGIN DECLARE SECTION;
|> /* User-defined type for null-terminated strings */
|> EXEC SQL TYPE asciz IS STRING(20);
|> asciz emp_name[20];
|> ...
|> EXEC SQL END DECLARE SECTION;
|>
|> and then do
|>
|> EXEC SQL SELECT ename INTO :emp_name FROM emp WHERE empno = 7499;
|>
|> and get a null-terminated C string in the emp_name host variable.
|>
|> There is also an EXEC SQL VAR ... command that let's you do external
|> type equivalencing on a variable-by-variable basis. The VAR command is
|> also available for the COBOL, FORTRAN, and PL/I precompilers.
|>
|>
|> --Tim (tssmith_at_netcom.com)
|> (tssmith_at_oracle.com)

I'm not clear on exactly what emp_name is after those two declarations. Is it a single character array or an array of twenty strings?

Is this part of the proposed ANSI SQL standard?

Philip Hall Received on Mon Mar 02 1992 - 23:53:20 CET