On Mon, Jun 25, 2012 at 3:29 PM, Vadim Zeitlin <vz-s...@zeitlins.org> wrote:
> NM> Definitely not, out parameters are part of the parameter set, not part
> of
> NM> the result set.
>
> Sorry, "definitely not" what?
>
output or input/output parameters should not be implemented with "into" as
an into represents a column in a result set, whereas a "use" represents a
parameter.
>
> NM> When we implemented using SOCI for ODBC for stored procedures (which
> was
> NM> supposed to be not supported) we did not find any support for output
> NM> parameters and we handled these with ODBC "direct". In our library we
> used
> NM> vector<char> as the type for receiving strings.
>
> You shouldn't have been able to make this work with use() parameters
> without modifying the SOCI sources. They currently unconditionally use
> SQL_PARAM_INPUT for binding and only SQL_PARAM_INPUT_OUTPUT parameters can
> be modified by ODBC.
>
I recall that is one way I determined it was definitely not currently
supported and our feeling was that we would use SOCI where we could, modify
it only where it was buggy for our purposes and write our own code where
SOCI didn't fit our needs. SOCI not supporting output parameters is a
missing feature not a bug therefore we didn't implement it. SOCI failing to
call SQLMoreData or whatever the call when retrieving results is a bug.
>
> NM> The ideal way would be use() variations that take (non-const) pointers.
>
> IMHO this is not ideal at all. When you have a local (hence non-const)
> variable that you're writing to the database you absolutely don't expect it
> to be modified in the process of being saved.
>
An output parameter is intended to be written to. Non-const references
would conflict with a lot of the current code. There is currently no use()
that takes a pointer so it would be an addition to the code and not break
anything that works now. Obviously you must ensure it is not the address of
a local variable that won't exist after the call.
As the use creates a wrapper class, for non-standard types it could use
some in-between value that really gets bound and then you copy the value
across after the call.
For our own code we had our own "wrapper" class which was there to abstract
the implementation out but the bind went direct to the supplied user
variable. For a string the user supplied a vector<char> (reference) preset
to the maximum length so there was no need to pass in a length parameter
too.
For an input/output parameter where the input can be null you need a flag
for this as you cannot use a null pointer or you have nowhere to write the
output.
>
> Ideal would be to clearly distinguish between input and input/output
> parameters and this would require a new syntax.
>
>
We used an additional flag to indicate if it is input/output rather than
just output. In our case though I don't think it ever was. use() could be
implemented to take more than one parameter so something like:
use( T * x, bool isInOut = false, bool isNull = false )
if isNull flag is only appropriate for in-out parameters to indicate if you
have passed in a null input parameter. You need to know if you got a null
back so you might actually want to put in the indicator in a different way
so you can read back if you got a null too.
> Regards,
> VZ
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Soci-users mailing list
> Soci-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/soci-users
>
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Soci-users mailing list
Soci-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-users
