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

Conference orarep::nomahs::sql

Title:SQL notes
Moderator:NOVA::SMITHI
Created:Wed Aug 27 1986
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3895
Total number of notes:17726

3862.0. "Bad RDML output re indexed dates" by ORAREP::ESOSRV::BATOR () Thu Feb 13 1997 15:59

Converting an old legacy application to SEPS97 standards on USTEST::
    i.e. VMS V6.2, RDB V6.1-04, Pascal V5.4, RDML V6.1-04
We ran into a problem where the RDML output is invalid syntax to the
Pascal compiler.  It only affects date fields that are in an array.
We proved that the RDML output is bad by manually editing the generated
.pas file and then getting a clean compile from Pascal. Other lines of
code with the same date fields are OK if they are not indexed. 

Below, I excerpted details of the offending source line, its .pas output,
and the .lis output; then the corrected form, plus resulting successful
.lis output.  

  Any one have any idea, or where to turn, since it
is a pain to manually edit every other step in a build stream?

==========================================================================

[[[this is the source line (at ==>>) in question, from the .rpa file ]]]
...
                   MODIFY MCS USING 
                      ON ERROR
                        r_stat := cpcrs$$check_db_status(RDB$MSG_VECTOR[2]);  
                      END_ERROR;
                      MCS.custom_flag := in_sec[cnt].custom_flag;
=>>>                  MCS.mod_date := in_sec[cnt].mod_date;
		      MCS.section_title := in_sec[cnt].section_title;
                   END_MODIFY;
...

==========================================================================
[[[ This is from the .pas file generated by RDML; First, a typical date 
   statement that compiles OK ]]]

(* 5542 *)   		(* c_s.mod_date := mcs.mod_date; *)
	    C_S.MOD_DATE::RDML$CDDADT_TYPE
 := RDB$MSG_PORT_40_0.RDB$PORT_FIELD_1
;
=====================================================================
[[[ but, farther down, if the date field is indexed, then RDML creates
  this statement in the .pas, which DOES NOT compile ]]]

(* 5555 *)                         (* MCS.mod_date *)
		RDB$MSG_PORT_40_0.RDB$PORT_FIELD_1

 := in_sec::RDML$CDDADT_TYPE
[cnt].mod_date;
==========================================================

[[[ and from the .lis ]]]

17980   C  1 10 (* 5555 *)                         (* MCS.mod_date *)
17981      1 10 		RDB$MSG_PORT_40_0.RDB$PORT_FIELD_1
17982      1 10 
17983      1 10  := in_sec::RDML$CDDADT_TYPE
		            1
%PASCAL-E-SIZCASTYP, (1) Variable's size conflicts with cast's target type
17984      1 10 [cnt].mod_date;
		1
%PASCAL-E-MSTBEARRVRY, (1) Type must be ARRAY or VARYING
====================================================================
====================================================================
[[[ now, if you edit the .pas so the "..CDDADT..." qualifier is at the END 
  of the statement, then it compiles without error. Conclusion: The RDML 
  pre-compiler's output does not produce a syntax acceptable to PASCAL. ]]]

e.g.  [[ result of manually editing ]]
(* 5555 *)                         (* MCS.mod_date *)
		RDB$MSG_PORT_40_0.RDB$PORT_FIELD_1

 := in_sec[cnt].mod_date::RDML$CDDADT_TYPE;

(* 5556 *)   		      (* MCS.section_title *)

==================================================================
[[[ this is now the .lis output  (Warning only and not an error)  ]]]

17980   C  1 10 (* 5555 *)                         (* MCS.mod_date *)
17981      1 10 		RDB$MSG_PORT_40_0.RDB$PORT_FIELD_1
17982      1 10 
17983      1 10  := in_sec[cnt].mod_date::RDML$CDDADT_TYPE;
		                1
%PASCAL-W-EMPTYVAR, (1) Fetching an empty record with an explicit size attribute may not yield expected results
17984      1 10 
17985   C  1 10 (* 5556 *)   		      (* MCS.section_title *)
...
T.RTitleUserPersonal
Name
DateLines