FreeTDS Development Group

["Brian Bruns" <camber AT ais.org>]

Actually Mark, I have to take all this back.  You are absolutely correct.  
When DBD::Sybase sets the property it passes &imp_dbh....imp_dbh is a local 
variable and is subsequently tossed.  So, simply storing 'buffer' is wrong. 
 Now I'm mallocing space and memcpy()'ing the data in.  In this case the 
data is a pointer.

All the tests work except for autocommit, which hangs on 2....I'll look at 
it tommorow :)

Brian

Everything should be in CVS shortly.

On 08/25/99, "Brian Bruns <camber AT umcc.ais.org>" wrote:
> On Wed, 25 Aug 1999, Mark Schaal wrote:
> 
> > > 
> > > Mark Schaal writes:
> > >  > >
> > >  > > Actually that's changed and checked in.  I found the same 
> > > thing...but I
> > >  > > still get main.t to crash.  That's against a Sybase 11.x server 
> > > (the JDBC
> > >  > > server at Sybase)
> > >  > > 
> > >  > > Brian
> > >  > 
> > >  > I think you should be saving the data in the buffer and not the 
> > > buffer
> > >  > itself.  I could be wrong...
> > > 
> > > I don't think so.
> > > 
> > > I sort of figured that you only store the pointer to the buffer that
> > > is passed in, and it's length. Otherwise, when the app changes the
> > > data in that buffer it won't be reflected in the CS_USERDATA buffer.
> > > 
> > > Michael
> > 
> > <*sigh*> If only we had ctlib documentation.
> >
> 
> I've got dblib/cslib/ctlib/server lib manuals :P
> 
> Seriously, you can go to sybooks.sybase.com and all the manuals are on
> line, although sqml to html garbage they use is slow enough to drive you
> crazy.
> 
> The doc states *buffer is 'user allocated data'.  Although a little vague
> it seems to indicate that the user is responsible for keeping the data
> and releasing it...If I was at work I could test it fairly simply, just
> store it change it and then ask for it back.
> 
> > I think I look at the incoming buffer as just a generic buffer that
> > may be reused, resized, or thrown away.  That's why I think the data
> > in the buffer is the critical item.  Also my intuition favors looking
> > at the CS_USERDATA as private so I wouldn't want the app to change it.
> > This should be analogous to setting, say, CS_USERNAME where you don't
> > want the app to change it without going through ct_con_props().
> > 
> > It doesn't seem to make sense to pass in the length of the buffer if
> > all you store is the buffer's pointer.
> > 
> 
> Well its a multifunction function, so to speak.  So whether buflen has any
> application to this property is debatable.
> 
> > The alternative of storing the pointer and the length doesn't make
> > sense because the buffer length is never returned.
> > 
> > So, those are my arguments. (Also my version didn't core dump, which
> > should count for something. :-)  Maybe I'll change my mind tomorrow.
> >
> Okay, but if I store a CS_CONNECTION structure as USERDATA now I have two
> places in memory with different states if I copy it.  That is, close one
> connection does it think its duplicate is still open? It gets messy.
> 
> Anyway, the USERDATA stuff works...I get a valid address for the
> struct and it is intact...It crashes later in a seemingly unrelated way.
> 
> > Adios,
> > 
> > Mark
> > -- 
> > Mark J. Schaal                                      Phone:      (909) 
> > 620-7724
> > TST On Ramp                                 Fax:        (909) 620-8174
> > System Administrator                                E-Mail: 
> > mark AT tstonramp.com
> >