RE: back-sql considered experimental?

["Ardhanareeswaran, M P (Mp)" <mpa1@lucent.com>]

All:

I have been trying to get a 32/64 bit version of this module working with little luck.   Here are some details:

- Version 2.1.25
- Database TimesTen 4.5.x.
- OS: Solaris 2.9
- Compiler: cc: Sun C 5.5 Patch 112760-09 2004/03/31

- The examples did not work as I expected; my expectations may be wrong.
- documentDN attribute is missing definition in inetOrgPerson schema.
- A query such as 
ldapsearch -L  -v -D "cn=root,o=sql,c=RU" -w secret -s sub -p 20001 -h myhost.mycompany.com -b "cn=root,o=sql,c=RU" "(objectClass=*)"

returns nothing.  Anything wrong here ?  I see request reaching the server.

- 64 bit causes bus errors.
- BACKSQL_TRACE macro causes compilation errors.

Any ideas as to what may be happening here.  I will leave it as experimental.

m.p. ardhanareeswaran


-----Original Message-----
From: Rubin [mailto:rubin@vt100.nl]
Sent: Saturday, June 12, 2004 4:31 AM
To: openldap-software@OpenLDAP.org
Subject: back-sql considered experimental?


Hi OpenLDAP Users/Developers,

I'm wondering if back-sql is still considered experimental, taking into
account the fact that a lot of people are building solutions based on
back-sql. The manual page for back-sql still denotes it as experimental
but it hasn't been updated for quite some time I think.

The reason for this question is that I'm talking Nalin Dahyabhai, who is
the maintainer for the OpenLDAP package for RedHat. I recently asked him
if it would be possible to include back-sql support in the openldap
package and he thought it was a good idea to include certain backends as
dynamic-modules but wasn't sure about back-sql, since its man page tells
us it is still experimental.

I've been making various solutions using back-sql and I haven't run into
any huge "oh my god this is experimental"  bugs and I hope some people
on this list are willing to clarify this issue, So I can mail Nalin with
some reassurance regarding back-sql's stability ;-).

Kind regards + thanks for anyone's time,

Rubin Simons.