Re: PROC: Dynamic SQL

From: Michael Krolewski <mkrolews_at_upw.com>
Date: 1996/07/30
Message-ID: <31FE3200.5009_at_upw.com>#1/1


Brad Maxwell wrote:
>
> Vandra Huber wrote:
> >
> > Reinhard Schmidt wrote:
> > >
> > > > Hi All,
> > > > I have a Probelm with dynamic sql in PRO*C.
> > > > the sql statement is like " select * from mytable where name = :f1".
> > > > it works fine if the bind variable has all the N chars , where N
> > > > is the length of the coulmn name. but it returns nothing if the bind
> > > > variable has a value whose length is less than the column
> > > > length. Any ideas?
> > > >
> > > > thanks a lot, ash.
> > > >
> > > Is your bind variable char or varchar. I recommend to use varchar and to set
> > > varchar.len accordingly.
> > >
> > > ----
> > >
> > > Reinhard Schmidt Reinhard_at_schmidt.do.eunet.de
> >
> > EXEC SQL select ... into :myVariable :myIndicatorVariable ...;
> >
> > The variable is 0 (zero) if successful, -1 if null or +1 if ???
> > In any case, if the indicator is not there, nothing is done..
>
> I'd like to complicate this question further.
>
> I have a situation where I don't know how much space to allocate before
> I fetch. I've got binary data in a LONG RAW field and the user could
> have stored as much data as he wanted (within the limits). I can make a
> guess at how much to allocate before my fetch, but if it fails, I can't
> go reallocate and try again because I don't have a unique key for that
> table to identify the row that gave me the problem.
>
> Any ideas?
>
> Brad

Brad:

The ProC would require that a variable of sufficient size to receive the largest possible element.

I might suggest that since this is C, program the solution. The fetch can get the data back in one large block. Then use C to rearrange the data into a suitable structure which is more compact.

Also, remember to include an indicator variable in the event that the buffer is too small or null. Otherwise nothing is processed.

Mike Krolewski
in one large block Received on Tue Jul 30 1996 - 00:00:00 CEST

Original text of this message