Try these:
1. Can you execute an insert using isql interface from your 64 bit client?
2. Do you have difference in charactersets or encodings on client that was
not on other 64 bit machine (Sybase 12.5 is more sensitive to i18n stuff
than 12.0).
3. Though this may not apply but if the connection has some pending result
set you will get errors (not this one though).
Can you share a small snippet of code where you think the problem occurs?
Maybe you are specifying the size of data based on 64 bit units instead of
32bit units. Unlikely but possible.
HTH,
-----------------------------------------------------------------
Amit Jindal, Development Engineer
Want ease of development or performance? Why not get both!
http://www.roguewave.com/products/sourcepro/db/
[Disclaimer: All views expressed here are my personal views and they can be
incorrect at times]
-----------------------------------------------------------------
"Henk van der Wal" <none@noware.nl> wrote in message
news:3F57441F.9010901@noware.nl...
> Pablo Sanchez wrote:
> > Henk van der Wal <none@noware.nl> wrote in
> > news:3F55F146.5020209@noware.nl:
> >
> >
> >>According to sybase docs error 4020 occurs when the receiving
> >>buffer of the server is too small. As possible reasons they list:
> >>1 application errors
> >>2 corrupt packets being transmitted
> >>3 incorrect network configuration
> >>
> >>Since the aplications haven't changed (except for being compiled
> >>64 bits) and the server is on the same machine as the client, all
> >>causes don't seem applicable (apps run already without problems on
> >>OSF 64 bits).
> > Since you're using 64-bits, the memory model is different than
> > 32-bits. This means that your application has changed and it's very
> > possible that any bad pointers that weren't showing in 32-bit mode
> > are
> > now being uncovered. 
>
> The applications already run on 64 bits Alpha so pointer problems are
> not likely.
> Furthermore, we use lint and Purify to check our sources.
> What maybe of significance is that the problem occurs on the second call
> of a stored procedure that returns an image field. After the first call,
> ct_cancel is called (something we can see in a truss of the application).
>
> Hans van Eck/Henk van der Wal
>