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} **