Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!hal!ncoast!telotech!bsa
From: bsa@telotech.UUCP (Brandon S. Allbery)
Newsgroups: comp.databases
Subject: Re: ORACLE: PRO*C: dynamic sql specifications sought
Message-ID: <1989Sep25.172126.10612@telotech.uucp>
Date: 25 Sep 89 17:21:26 GMT
References: <693@cullsj.UUCP>
Sender: bsa@telotech.uucp (Brandon S. Allbery)
Reply-To: bsa@telotech.UUCP (Brandon S. Allbery)
Organization: _
	      telotech, inc. - Beachwood, OH
Lines: 26
In-reply-to: brad@cullsj.UUCP (Brad Might)

In article <693@cullsj.UUCP>, brad@cullsj (Brad Might) writes:
+---------------
| 	Basically, any SQL statement legal in SQLPLUS can be
| 	passed in as a string via dynamic SQL (perhaps variable
| 	substitution is excluded here)...
> . . .
| 	Handling Numbers via dynamic sql is not too pleasant.
+---------------

Why?  Embedded SQL should include "binding":  use a question mark in place of
a value which may vary and place a pointer to the value in the bind structure
for that question mark.  You then have to call the input bind function before
executing the SQL statement.  (I do not give details because it can vary --
hey, ANSI, how about an embedded SQL API standard? -- and I don't remember how
to do it for Oracle, although I *have* done so and it works fine.)

Note that the embedded SQL API should include translation to the host language
number format:  if ESQL insists that you bind a number in its internal number
format (e.g. base-100), complain loudly to your DBMS vendor.

++Brandon
-- 
-=> Brandon S. Allbery @ telotech, inc.   (I do not speak for telotech.) <=-
Any comp.sources.misc postings sent to this address will be DISCARDED -- use
allbery@uunet.UU.NET instead. My boss doesn't pay me to moderate newsgroups.
** allbery@NCoast.ORG ** uunet!hal.cwru.edu!ncoast!{allbery,telotech!bsa} **