Porting from Ingres ESQLC to Pro*C

From: Mike Peterson <mtp_at_mold.zso.dec.com>
Date: 19 Feb 93 22:46:09 GMT
Message-ID: <1993Feb19.224609.16505_at_ninja.zso.dec.com>

Problem statement:

We're porting a large C-language program from Ingres to Oracle. The source contains lots of embedded SQL and we've run into what appears to be some rather significant obstacles imposed by the differences between Ingres ESQLC and Oracle's Pro*C. We're hoping that someone can provide some information that will help us overcome them. Here we go:

Ingres Embedded-SQL/C supports many of the C language mechanisms which allow datatype abstraction (e.g, #define, typedef, struct), Oracle Pro*C apparently suports a much smaller subset of these mechanisms. When using Ingres, datatype abstractions can be placed in an .h file which is EXEC SQL INCLUDE'ed, with the ability to use the same .h file in native .c modules.

This is apparently impossible with Oracle Pro*C!

Question:
Has anyone out there who has been faced by this problem developed any tools or workarounds which can make the use of Pro*C a little less cumbersome ?

Examples follow.

                                Ingres example

The following code mechanisms are supported by ESQLC: The code shows the use of a ESQLC function which returns a structure, because this is our desired code design (error detection is omitted for brevity). NOTE: While Ingres ESQLC does support the #define shown below, they do NOT support other precompiler directives, e.g., #ifndef, etc.

/*

• The following typedefs would go in an .h file, e.g. foo.h */ #define NAMELEN 20 typedef char name_t[NAMELEN+1]; typedef short dept_t; typedef long empno_t;

typedef struct _emp_rec_
{

    name_t name;
    empno_t empno;
    dept_t dept;
}
emp_rec_t;

/*

• The following code fragment uses the typedefs above */ EXEC SQL BEGIN DECLARE SECTION; EXEC SQL INCLUDE 'foo.h'; EXEC SQL END DECLARE SECTION;

void
get_record ( *erec )

    EXEC SQL BEGIN DECLARE SECTION;
        emp_rec_t *erec;
    EXEC SQL END DECLARE SECTION;
{

    EXEC SQL SELECT

        name,
        empno,
        dept 
    INTO 
        :erec->name,
        :erec->empno,
        :erec->dept
    FROM
        emp
    WHERE
        .... search conditions .... ;

}

                                 Oracle Pro*C:

The code shows the mechanisms (used in the Ingres example above) used in a single, simple main(), because it illustrates the problems in a slightly simpler way.

#define NAMELEN 20                      /* Ignored by Pro*C */
typedef char name_t[NAMELEN+1];         /* Ignored by Pro*C */
typedef short dept_t;                   /* Ignored by Pro*C */
typedef long  empno_t;                  /* Ignored by Pro*C */

typedef struct _emp_rec_                /* Ignored by Pro*C */

{

    name_t name;
    empno_t empno;
    dept_t dept;
}
emp_rec_t;

main()
{

    EXEC SQL BEGIN DECLARE SECTION;

/* Pro*C must do the follwing to abstract the simple data types, but obviously

• the following code cannot be shared in an .h file which is shared by
• non-embeddedSQL .c files. */ EXEC SQL TYPE name_t IS STRING(21); EXEC SQL TYPE empno_t IS INTEGER(4); EXEC SQL TYPE dept_t IS INTEGER(2);

/*

• Pro*C does not support structs at all, so the following causes errors in
• any case. */ emp_rec_t erec; /*
• Only simple datatypes can be declared. */ name_t name; empno_t empno; dept_t dept;

    EXEC SQL END DECLARE SECTION;

/*

• The follwing SELECT statement produces a Pro*C error, because of the
• struct elements */ EXEC SQL SELECT name, empno, dept INTO :erec.name, /* Totally unsupported */ :erec.empno, :erec.dept FROM emp WHERE .... search conditions .... ;

/*

• Alternatively, we must do something like this */ EXEC SQL SELECT name, empno, dept INTO :name, /* Simple datatypes only */ :empno, :dept FROM emp WHERE .... search conditions .... ;

    strcpy ( erec.name, name ); /* Load the structure manually */     erec.empno = empno;
    erec.dept = dept;
}

I have heard the Pro*C 2.0 has planned support for structs, I don't know if they plan to directly support native C typedefs (making the EXEC SQL TYPE statements unecessary) or any of the # directives. In any case, we can't wait.

Regards,

-- 
#
#      +--------------------------------------------------------------+
#      | Michael T. Peterson          | Bellevue, Washington          | 
#      |--------------------------------------------------------------|

Received on Fri Feb 19 1993 - 23:46:09 CET