[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: back-sql writes binding improperly

Brad Midgley wrote:


I'm trying to allow updates through back-sql. I have add_proc for
telephoneNumber defined as:

'update utahlink..educator set phone=? where teacher_id=convert(integer,?)'

Does that look ok with the parameters? param_order is 3 by the way. I have to convert(integer,?) numbers because all numbers are getting bound as varchars by freetds. (yes, it's a pain.)

s..t happens :) Anyway, I note from the code that the parameter is bound as char only if compiled with -DBACKSQL_ARBITRARY_KEY (something that must be defined manually); otherwise the default is to bind as integer.

The update looks like:

$ ldapmodify -H ldap://iceman.uen.org -D uid=admin,dc=my,dc=uen,dc=org
-x -W -f ~/mid
modifying entry "uid=bmidgley,dc=my,dc=uen,dc=org"

$ cat mid
dn: uid=bmidgley,dc=my,dc=uen,dc=org
telephoneNumber: 801-555-5555

But then the freetds log shows that it is being executed as:

update utahlink..educator set phone='' where

The value of the phone number is nowhere to be found in what's being executed. Any idea what happened?

No. Just tested with the default metadata comng from the sources (2.2 and HEAD)
and it works as expected. The add_proc for PostgreSQL looks like
"SELECT add_phone(?,?)" with param_order=3 and should be substantially
analogous to yours.

Which part of add.c should I look at?

backsql_modify_internal() in add.c; if you use loglevel of 1 (ORed to whatever
you're using) a (very) verbose log of what back-sql does appears. Unfortunately
the parameters of this operation are not shown, I'm fixing this in HEAD. Note
that logging values of attributes is not a good practice (think of logging a
password...) so all the messages that are logged right now about data values should
be considered temporary and for debugging purposes only. I plan to remove
them at some point, when the backend can be considered feature-frozen.


   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497