FreeTDS Development Group

[Joshua Lang <joshua.h.lang AT gmail.com>]

I went back and re-read the entire thread and I see the problem you are
referring to with the desire of the input parameter to be NULL, but still
support an output parameter. I don't see a good way for the DB-lib API to
support this directly. Even still, the ability to pass NULL pointers for
input only parameters would be nice.

One could add a new method (e.g. dbrpcparam2), which had distinct inputs
for both input and output parameters instead of using the same pointer
'value' for both input data and output buffer.



On Thu, Mar 17, 2016 at 11:54 PM, Frediano Ziglio <freddy77 AT gmail.com>
wrote:

> The problem is distinguish between null and empty. By definition 0 is null
> and - 1 is not accepted. Another negative value could work and a program
> could detect of library is FreeTDS or not and use this value (FreeTDS) or 0
> (ms or sybase). Libraries do not have same abi so a compile time check
> would be fine. Other libraries use 1 as length and fill the byte to a
> specific value (like space for varchar and 0 for binaries)
> On 17 Mar 2016 03:45, "Joshua Lang" <joshua.h.lang AT gmail.com> wrote:
>
> > I assume you're referring to input/output parameters where the input
> value
> > is NULL, but the output value is non-NULL?
> >
> > The MSDN docs for rpcparam (
> > https://msdn.microsoft.com/en-us/library/aa937102(v=sql.80).aspx) don't
> > really indicate how this case is handled, but
> > I think the following would work for the input/output parameter:
> >
> > maxlen = <maximum desired length of return value>
> > datalen = 0
> >
> > Basically maxlen is used for the length of the output parameter buffer
> and
> > datalen is the length of the input data.
> >
> > Thoughts?
> >
> >
> > On Tue, Mar 15, 2016 at 4:37 PM, Frediano Ziglio <freddy77 AT gmail.com>
> > wrote:
> >
> > > I was looking at this issue. The problem raise when you want a return
> > > value but you want to pass a empty or a NULL varchar. How to
> > > differentiate in this case? value cannot be NULL for return
> > > parameters.
> > >
> > > Frediano
> > >
> > >
> > > 2016-01-19 18:25 GMT+00:00 Joshua Lang <joshua.h.lang AT gmail.com>:
> > > > I've read that older versions didn't even support passing 0-length
> data
> > > > (prior to TDS 7.0 I believe). If this could be supported for later
> > > versions
> > > > of TDS 7.0, that would be great.
> > > >
> > > > Thanks.
> > > >
> > > > On Tue, Jan 19, 2016 at 2:52 AM, Frediano Ziglio <freddy77 AT gmail.com
> >
> > > wrote:
> > > >
> > > >> 2016-01-16 1:41 GMT+00:00 Joshua Lang <joshua.h.lang AT gmail.com>:
> > > >> > In the latest version of FreeTDS-dblib (0.95.79) I'm passing rpc
> > > VARCHAR
> > > >> > parameters of 0 length, but non-NULL (empty strings). FreeTDS
> seems
> > to
> > > >> turn
> > > >> > these into NULL values before passing them on to SQL Server. From
> > what
> > > >> I've
> > > >> > read, it seems as if older databases didn't support passing empty
> > > >> strings,
> > > >> > but newer ones do? (i.e. TDS 7.0+ do support empty strings).
> > > >> >
> > > >> > It seems as this is a known issue, but I was wondering if it is
> > > possible
> > > >> to
> > > >> > fix it for the newer versions of SQL server? E.g. in dbrpcparam()
> > > >> passing a
> > > >> > non-NULL pointer to the 'value' parameter and a 0 to 'datalen'
> would
> > > >> > indicate an empty string is desired if possible.
> > > >> >
> > > >> > Thoughts?
> > > >>
> > > >>
> > > >> The main problem is not libTDS (the code library) but dbrpcparam
> > > >> specification.
> > > >> datalen < 0 is invalid for variable fields (like VARCHAR) and 0 is
> > used
> > > >> for NULL
> > > >> value (no matter the data pointer). But looks like your suggestion
> > > >> (not NULL value
> > > >> and 0 datalen) could be a good choice.
> > > >> Not sure however if this could work with all types and server
> versions
> > > >> (for instance
> > > >> 0 size TEXT).
> > > >> We can do it but I'm not thinking about backporting it to 0.95.
> > > >>
> > > >> Frediano
> > > >> _______________________________________________
> > > >> FreeTDS mailing list
> > > >> FreeTDS AT lists.ibiblio.org
> > > >> http://lists.ibiblio.org/mailman/listinfo/freetds
> > > >>
> > > > _______________________________________________
> > > > FreeTDS mailing list
> > > > FreeTDS AT lists.ibiblio.org
> > > > http://lists.ibiblio.org/mailman/listinfo/freetds
> > > _______________________________________________
> > > FreeTDS mailing list
> > > FreeTDS AT lists.ibiblio.org
> > > http://lists.ibiblio.org/mailman/listinfo/freetds
> > >
> > _______________________________________________
> > FreeTDS mailing list
> > FreeTDS AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/freetds
> >
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>