ProC - sqlcheck=semantics without connection to a database - handling views

Question

Hello!
I have a question about ProC and embedded SQL. I'm not sure if this falls under
the OCCI umbrella but when I originally posted my question to the SQL forum I
was directed to the OCCI forum. My apologies if my question is off-topic here as well.
We would like to run ProC with sqlcheck=semantics without connecting to a database..
To do this we insert an
EXEC SQL INCLUDE definitions.pc;
in each of our source files containing embedded sql. The file definitions.pc contains
a set of statements of the form "EXEC SQL DECLARE xxx TABLE ( .... );".
This file is generated from another file containing "CREATE TABLE" statements.
This seems to work, if our embedded SQL does not agree with the table definitions
in definitions.pc then ProC complains.
We would now like to get semantic checking for embedded SQL that refers to views
but are unsure how to achieve this. There does not seem to be a statement
"EXEC SQL DECLARE xxxx VIEW".
One way to do this would be to add a fake "EXEC SQL DECLARE xxx TABLE"
statement to definitions.pc for each view in the database. Writing a tool that translates
a set of "CREATE TABLE" into a set of "EXEC SQL DECLARE TABLE" is easy, but
translating "CREATE VIEW" into a corresponding faked "EXEX SQL DECLARE xxx TABLE"
seems much harder.
Is there a way to achieve semantic checking of embedded SQL that refers to views
without connecting to a database or without writing a tool that parses full "create view"
statements?
Thanks,
Lars

Answer 1

I'm not sure if this falls under the OCCI umbrellaOnly in the same way that questions about chalk fall under the cheese umbrella.
Pro*C and OCCI are different subjects.
We would like to run ProC with sqlcheck=semantics without connecting to a database.Sorry, that's impossible; it's a direct contradiction. sqlcheck=semantics REQUIRES a connection to the database, otherwise the SQLCHECK cannot check the SEMANTICS; to do that it needs to connect to the database.
If you cannot connect to a database then you can't use sqlcheck=semantics, which in turn means you can't use embedded PL/SQL.
However you can use Dynamic PL/SQL, which means you have the PL/SQL in a character string and explicitly code what Pro*C does for you automatically. There are very few changes needed to accomplish this, and no change in performance as what you would be doing explicitly in code is exactly the same as what Pro*C does for you in the background; the only difference is syntactic sugar.
If code changes are impossible and you must have a database, then you will have to install one on the development machine and load into it the objects that Pro*C needs to check in order to complete the semantic check. What isn't checked is that the database at precompile time is the same as the database at runtime, so this is a valid solution.