Re: Ugly embedded SQL behaviour

From: John D Groenveld <groenvel_at_sml.cse.psu.edu>
Date: 2 Sep 1994 02:38:28 GMT
Message-ID: <346375$bu6_at_psuvax1.cse.psu.edu>


In article <CvGn1M.Ewq_at_world.std.com> smayo_at_world.std.com (Scott A Mayo) writes:
>
>I'm irritated at Oracle's embedded SQL (Pro*c) product. I
>found a bug that cost me two days on a tight schedule. I'm
>posting this so other folk won't hit the same trap.
>
>Given this sequence:
>
> EXEC SQL BEGIN DECLARE SECTION;
> static char buf[32000]; /* big buffer to build SQL command in */

         ^^^^
perhaps declaring this as varchar would help?

> EXEC SQL END DECLARE SECTION;
>
> ... buf gets used for various things ...

 			^^^^^^^^^^^^^^

I vaguely remember the proc book recommending that you declare different buffers for each SQL command, I could be wrong though.

*stuff deleted*
>
>It turns out that, while buf contains exactly the text
>implied by the strcpy, terminating nul character and
>all, the Execute immediate parsing didn't stop when
>it saw the nul character. It looked deeper into the
>buffer, saw the remains of other strings, and declared
>the error.
>
 *stuff deleted*
>
>If you are considering using Oracle embedded SQL products, and
>have a choice between it and Informix, take another look at
>Informix. I've had two weeks of pain with Oracle, and have learned
>the fine art of being on hold, waiting for support people to
>get to me. The informix stuff went quite smoothly by comparison.

I agree that waiting for tech support is a pain, but I found that if I put off my non-urgent calls til after 5pm est that I can get through within 5 minutes.

Happy Pro*C coding,
John
groenvel_at_cse.psu.edu Received on Fri Sep 02 1994 - 04:38:28 CEST

Original text of this message