Re: [Refdb-users] DUMMY style entries

[Markus H. <hoe...@co...>]

Denis Crowdy writes:
 >  
 > I tried adding the styles from the source (although my other styles were
 > very simple adaptations of the examples that were valid).  This is the
 > output from refdbd.log -
 > 
 > 7:pid=7231:Fri Jun 14 02:24:19 2002:INSERT INTO CITSTYLE (JOURNAL)
 > VALUES ('DUMMY')
 > 7:pid=7231:Fri Jun 14 02:24:19 2002:UPDATE CITSTYLE SET
 > JOURNAL='Eur.J.Pharmaco l.' WHERE ID=0
 > 7:pid=7231:Fri Jun 14 02:24:19 2002:INSERT INTO REFSTYLE (CITSTYLEID,
 > PUBTYPE) VALUES (0, 'GEN')
 > 7:pid=7231:Fri Jun 14 02:24:19 2002:UPDATE REFSTYLE SET
 > AUTHORLISTFOLLOWING='.  ' WHERE CITSTYLEID=0 AND PUBTYPE='GEN'
 > 7:pid=7231:Fri Jun 14 02:24:19 2002:UPDATE REFSTYLE SET
 > AUTHORLISTAUTHORSEPSTWO SEPS=' and ' WHERE CITSTYLEID=0 AND PUBTYPE='GEN'
 > 
 > and so on until the end ...
 > 
 > 7:pid=7231:Fri Jun 14 02:24:24 2002:SELECT ID FROM CITSTYLE WHERE
 > JOURNAL='Eur.J.Pharmacol.' ORDER BY ID ASC
 > 6:pid=7231:Fri Jun 14 02:24:24 2002:chunk added successfully
 > 7:pid=7231:Fri Jun 14 02:24:24 2002:command processing done, finish
 > dialog now
 > 6:pid=7231:Fri Jun 14 02:24:24 2002:child finished client on fd 6
 > 

All this looks just fine. There is no hint of anything going wrong.

 > I had reinstalled mysql a couple of weekends ago, and as a result seemed
 > to have wiped /etc/mysql/my.cnf
 > 

Did you use a different MySQL version previously, by any chance?

 > I have fixed this and restarted the mysql server to no avail.  Entries
 > in CITSTYLE seem to contain all NULLS, and "select * from CITSTYLE where
 > JOURNAL="Eur.J.Pharmacol.";" gives me an empty set...
 > 
 > So I'm thinking that refdb is doing it's thing and sending all the right
 > sql statements to mysql, but that mysql somehow refuses to update the
 > tables without returning an error.  The user permissions in mysql look
 > OK to me, but I can only conclude that this is where the problem must
 > lie.  I had entries for localhost and my hostname in the user table that
 > had no username, and then N in every single field.  Should those N's be
 > Y's in the relevant places for refdbd?

The MySQL access control encourages to create users in the user table
with all N's. This allows you to connect to the server but you can't
do any harm otherwise. Entries in the db table add specific access
rights for a particular database. These entries should have at least
four Y's for a regular user. On my test system, the entries are:

mysql> select * from user where user='markus';
+-----------+--------+------------------+-------------+-------------+-------------+-------------+-------------+-----------+-------------+---------------+--------------+-----------+------------+-----------------+------------+------------+
| Host      | User   | Password         | Select_priv | Insert_priv | Update_priv | Delete_priv | Create_priv | Drop_priv | Reload_priv | Shutdown_priv | Process_priv | File_priv | Grant_priv | References_priv | Index_priv | Alter_priv |
+-----------+--------+------------------+-------------+-------------+-------------+-------------+-------------+-----------+-------------+---------------+--------------+-----------+------------+-----------------+------------+------------+
| localhost | markus | 71d16fc5770db9a5 | N           | N           | N           | N           | N           | N         | N           | N             | N            | N         | N          | N               | N          | N          |
+-----------+--------+------------------+-------------+-------------+-------------+-------------+-------------+-----------+-------------+---------------+--------------+-----------+------------+-----------------+------------+------------+
1 row in set (0.85 sec)



mysql> select * from db where user='markus';
+-----------+----------+--------+-------------+-------------+-------------+-------------+-------------+-----------+------------+-----------------+------------+------------+
| Host      | Db       | User   | Select_priv | Insert_priv | Update_priv | Delete_priv | Create_priv | Drop_priv | Grant_priv | References_priv | Index_priv | Alter_priv |
+-----------+----------+--------+-------------+-------------+-------------+-------------+-------------+-----------+------------+-----------------+------------+------------+
| localhost | test     | markus | Y           | Y           | Y           | Y           | N           | N         | N          | N               | N          | N          |
| localhost | refdbvar | markus | Y           | Y           | Y           | Y           | Y           | Y         | N          | N               | N          | N          |
| localhost | refdb    | markus | Y           | Y           | Y           | Y           | N           | N         | N          | N               | N          | N          |
| localhost | pubmed   | markus | Y           | Y           | Y           | Y           | N           | N         | N          | N               | N          | N          |
+-----------+----------+--------+-------------+-------------+-------------+-------------+-------------+-----------+------------+-----------------+------------+------------+
4 rows in set (1.62 sec)

The administrator account would of course have all Y's in the user
table, making entries in the db table unnecessary.

[from another post:]

 >7:pid=5041:Fri Jun 14 07:08:53 2002:UPDATE CITSTYLE SET
 >JANTHREELET='Jan' WHERE 
 >ID=2139062143
 >7:pid=5041:Fri Jun 14 07:08:53 2002:UPDATE CITSTYLE SET JANABBREV='Jan.'
 >WHERE I
 >D=2139062143

The only conspicuous thing that I could see from your logs is that the
ID values are almost certainly incorrect. In the first log cited
above, the ID ends up as 0, here it ends up as 2139062143. The column
has the auto_increment attribute and will as such start at 1 in a
fresh database, not at 0. If you delete entries and add new ones with
the RefDB client, the IDs will not be reused, though, but the value
2139062143 would mean that you showed a serious amount of persistence
when trying to add styles.

I cannot reproduce this problem on my system, so all I can do is to
make a few suggestions:

- do you have any other MySQL installation available in your network?

- would you mind trying a different version of MySQL?

- could you send a dump of the refdb database after "adding" a style
  (I understand it doesn't work, but I'd like to see precisely what
  data end up in the table). The table structure and data of the
  CITSTYLE table should be enough. A faint possiblity is that a newer
  version of MySQL cannot digest the dump created by MySQL 3.22 that
  is part of the RefDB sources. Use mysqldump for this purpose (let me
  know if you need assistance).

regards,
Markus

-- 
Markus Hoenicka <hoe...@co...>
http://ourworld.compuserve.com/homepages/hoenicka_markus/