Emile Heitor wrote:
> Hi Dmitry,
>
> I found the blocking-connection problem. It was a FreeBSD-thread
> problem. Compiling openldap with --without threads does the Job.
> Well, now it connects, surely got some little things more, but I'm on the
> right way :
>
> backsql_open_db_conn: SQLConnect() succeeded with info:<--damn I like this =)
me too ;) there is a return code in ODBC SDK - SUCCESS_WITH_INFO, which is
returned sometimes when I would not call it success at all ;)
like SUCCESS_WITH_INFO, error code XXX, insufficient access ;)
> load_schema_map(): error executing at_query:
> Return code: -1
> SQL engine state: S1000
> Native error code: 0
> Message: [Microsoft][ODBC SQL Server Driver]Connection is busy with
> results for another hstmt
> <==backsql_get_db_conn()
> ==>backsql_free_db_conn()
>
> Now it should be a simple db format problem.
>
Again, I'm not a MS SQL guru, but I recall it is one more _strange_ thing about
it... Default cursor type in MSSQL does not allow to execute another statement
before you fetch all information from first one, so there can be only one active
hstmt at a time.
The problem is solved by a call to SQLSetStmtOption(SET_CONCURRENCY...), but
since this tends to confuse RDBMSes other than MSSQL, i make a dirty hack,
and compare driver name to SQLSRV32.DLL before this - see sql_wrap.c,
backsql_Prepare().
I suppose that unlike Openlink, OOB returns its driver name instead of that
working on the other side of bridge, so this comparison fails, option is not
set, and stupid MSSQL doesn't work ;)
You could substitute right driver name there, or just wipe out the check, since
you use it with MS SQL only...
If anyone knows of general solution of this (like generally accepted options, or
a more consistent way to detect MSSQL), please mail... Maybe it's worth just
adding another conf directive like dbms_type ;)?
WBW, Dmitry
PS. CC to openldap-software to complement yesterday's discussion of back-sql
installation problems