Hallöchen!
I try using getref through a socket. The communication is as
follows:
'6\x00\x00\x00\x00' ==>
<== '000012-34-21-32\x00\x00\x00\x00'
'000getref -d biblio -u root -w 110069038082057\x00\x00\x00\x00' ==>
<== '000'
'000:AU:~Ast\x00\x00\x00\x00' ==>
<== '234'
(==> is sent by my client, <== is received by my client.) The
question is why I get the 234. It means "select failed". The
refdbd says:
--8<---------------cut here---------------start------------->8---
output encoding is:
UTF-8
SELECT DISTINCT t_refdb.refdb_id, [...] t_refdb.refdb_citekey FROM t_refdb WHERE refdb_type!='DUMMY' AND rset>
<charset name="cpA ORDER BY t_refdb.refdb_id
1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '<charset name="cpA ORDER BY t_refdb.refdb_id' at line 3
select failed
--8<---------------cut here---------------end--------------->8---
It looks like the memory area of the query was polluted with some
garbage. But something else is equally strange to me. If I request
via refdbc, the daemon says:
--8<---------------cut here---------------start------------->8---
output encoding is:
UTF-8
SELECT VERSION()
SELECT DISTINCT t_xauthor.refdb_id FROM t_xauthor INNER JOIN t_author ON t_author.author_id=t_xauthor.author_id WHERE t_xauthor.xauthor_type='part' AND t_author.author_name RLIKE BINARY 'Ast'
SELECT DISTINCT t_refdb.refdb_id, [...] t_refdb.refdb_citekey FROM t_refdb WHERE refdb_type!='DUMMY' AND t_refdb.refdb_id IN (1) ORDER BY t_refdb.refdb_id
[...]
command processing done, finish dialog now
--8<---------------cut here---------------end--------------->8---
So, the first SELECT DISTINCT (which finds the IDs) is missing in
the first version. Am I doing something very nasty here or is this
a bug?
Tschö,
Torsten.
--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: tor...@ja...
|
