We have now got SOCI to work to call Stored Procedures using ODBC.
In general:
- We used statement rather than procedure as the class. This is because we
are then able to call exchange() to add the parameters and intos later on.
- Fixed your auto_ptr to be pretty much the same as auto_ptr. Not sure why
you rewrote this but yours doesn't obey rule of 3 and I don't rely on
miracles.
- Modified to code to bind the results after the call to SQLExecute rather
than after SQLPrepare. The result sets are often not yet known on
SQLPrepare.
- This last one was the toughest and we struggled for a while, but a Stored
Procedure can generate more result sets than what you'd expect. So if
SQLNumResultCols gives you 0 columns, call SQLMoreResults and try again. Do
this until you either find some result columns or SQLMoreResults returns
SQL_NO_DATA or an error.
Incidentally where I am doing this work we are using SQL Server (migrating
there from Sybase) and we are not an insignificant company.
For some other operations (BCP) we are not using SOCI and are using ODBC
more directly.
This information is being shared for others who wish to use SOCI with ODBC
and call stored procedures.
------------------------------------------------------------------------------
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online.
Learn more at http://p.sf.net/sfu/ms-windowsazure
_______________________________________________
Soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users
