refdb-devel — List for RefDB developers

[Refdb-devel] [ refdb-Bugs-1552020 ] :UR:!~ search does not return expected set

[SourceForge.net <no...@so...>]

Bugs item #1552020, was opened at 2006-09-04 16:46
Message generated for change (Comment added) made by dreusser
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1552020&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: refdbd
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Dominik (dreusser)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: :UR:!~ search does not return expected set

Initial Comment:
If searching for records that do not match a certain
string in their URL, I expect to get all records that
do not include this string in the URL, including
records with an empty URL. However, the query seems not
to return records with empty URL. The sql-string should
include "t_link.link_url!~'string' OR
ISNULL(t_link.link_url)". This might also apply to
other exclusive searches.

----------------------------------------------------------------------

>Comment By: Dominik (dreusser)
Date: 2006-09-07 14:03

Message:
Logged In: YES 
user_id=1572139

I tested the current SVN version and got the results as I
expected them to be. Thank you very much :)

----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-09-06 01:51

Message:
Logged In: YES 
user_id=85809

The test database contained 50 datasets, not 48. Therefore
11+39 does add up. Sorry for the confusion.

----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-09-06 01:46

Message:
Logged In: YES 
user_id=85809

I've fixed three bugs that prevented exclusive author,
keyword, and link (UR, L1-L4) queries to work properly. I've
tested a database containing 48 references. Only 11 of these
have an URL. :UR:~.* returns 11 datasets, :UR:!~.* returns
39 datasets. I assume this is what you intended to get.
Please see whether the current SVN version works ok for you.
If not, I'd appreciate a simple and concise testcase
including the datasets, the queries, the results you get,
and the results you'd expect.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1552020&group_id=26091

[Refdb-devel] [ refdb-Bugs-1544021 ] broken dependencies in debian svn package

[SourceForge.net <no...@so...>]

Bugs item #1544021, was opened at 2006-08-21 08:40
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1544021&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Dominik (dreusser)
Assigned to: David Nebauer (davidnebauer)
Summary: broken dependencies in debian svn package

Initial Comment:
libperl-refdb-makestyle depends on refdb which in turn
conflicts refdb-clients.... 
So basically the new svn-packages are not installable.



----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2006-09-05 19:20

Message:
Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: David Nebauer (davidnebauer)
Date: 2006-08-22 06:44

Message:
Logged In: YES 
user_id=1080150

The problem was a lingering dependency on
libperl-refdb-makestyle which is no longer necessary since
RefDB::Makestyle is now supplied by refdb-lib.  I have
removed this dependency and the packages should install.

Please note that refdb-doc has been temporarily removed from
the refdb svn repository due to build problems.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1544021&group_id=26091

[Refdb-devel] [ refdb-Bugs-1552020 ] :UR:!~ search does not return expected set

[SourceForge.net <no...@so...>]

Bugs item #1552020, was opened at 2006-09-04 16:46
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1552020&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: refdbd
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Dominik (dreusser)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: :UR:!~ search does not return expected set

Initial Comment:
If searching for records that do not match a certain
string in their URL, I expect to get all records that
do not include this string in the URL, including
records with an empty URL. However, the query seems not
to return records with empty URL. The sql-string should
include "t_link.link_url!~'string' OR
ISNULL(t_link.link_url)". This might also apply to
other exclusive searches.

----------------------------------------------------------------------

>Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-09-06 01:51

Message:
Logged In: YES 
user_id=85809

The test database contained 50 datasets, not 48. Therefore
11+39 does add up. Sorry for the confusion.

----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-09-06 01:46

Message:
Logged In: YES 
user_id=85809

I've fixed three bugs that prevented exclusive author,
keyword, and link (UR, L1-L4) queries to work properly. I've
tested a database containing 48 references. Only 11 of these
have an URL. :UR:~.* returns 11 datasets, :UR:!~.* returns
39 datasets. I assume this is what you intended to get.
Please see whether the current SVN version works ok for you.
If not, I'd appreciate a simple and concise testcase
including the datasets, the queries, the results you get,
and the results you'd expect.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1552020&group_id=26091

[Refdb-devel] [ refdb-Bugs-1552020 ] :UR:!~ search does not return expected set

[SourceForge.net <no...@so...>]

Bugs item #1552020, was opened at 2006-09-04 16:46
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1552020&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: refdbd
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Dominik (dreusser)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: :UR:!~ search does not return expected set

Initial Comment:
If searching for records that do not match a certain
string in their URL, I expect to get all records that
do not include this string in the URL, including
records with an empty URL. However, the query seems not
to return records with empty URL. The sql-string should
include "t_link.link_url!~'string' OR
ISNULL(t_link.link_url)". This might also apply to
other exclusive searches.

----------------------------------------------------------------------

>Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-09-06 01:46

Message:
Logged In: YES 
user_id=85809

I've fixed three bugs that prevented exclusive author,
keyword, and link (UR, L1-L4) queries to work properly. I've
tested a database containing 48 references. Only 11 of these
have an URL. :UR:~.* returns 11 datasets, :UR:!~.* returns
39 datasets. I assume this is what you intended to get.
Please see whether the current SVN version works ok for you.
If not, I'd appreciate a simple and concise testcase
including the datasets, the queries, the results you get,
and the results you'd expect.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1552020&group_id=26091

[Refdb-devel] [ refdb-Bugs-1552068 ] Search in personal list does not work with the web interface

[SourceForge.net <no...@so...>]

Bugs item #1552068, was opened at 2006-09-04 09:16
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1552068&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface (example)
Group: None
Status: Open
Resolution: Later
Priority: 5
Submitted By: Dominik (dreusser)
Assigned to: Daniel O'Donnell (dpod)
Summary: Search in personal list does not work with the web interface

Initial Comment:
When searching for records in the personal list from
the webinterface, no records are returned. The
following change in line 90 of refdbsearch.php corrects
the problem:


replace       $cmd = $cmd."-p ";
with       $cmd = $cmd."-b $name ";


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2006-09-05 10:20

Message:
Logged In: NO 

Thanks. I'll try to add this to the version there now, but
as Markus said, I'm in the middle of a complete rewrite.

----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-09-05 00:52

Message:
Logged In: YES 
user_id=85809

The fix appears correct. The PHP interface was not updated
since the personal list implementation changed. However, I'd
prefer to leave it to Daniel as he may want to make use of
multiple personal lists and provide an entirely different
interface to this feature.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1552068&group_id=26091

[Refdb-devel] [ refdb-Bugs-1552068 ] Search in personal list does not work with the web interface

[SourceForge.net <no...@so...>]

Bugs item #1552068, was opened at 2006-09-04 18:16
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1552068&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface (example)
Group: None
Status: Open
>Resolution: Later
Priority: 5
Submitted By: Dominik (dreusser)
>Assigned to: Daniel O'Donnell (dpod)
Summary: Search in personal list does not work with the web interface

Initial Comment:
When searching for records in the personal list from
the webinterface, no records are returned. The
following change in line 90 of refdbsearch.php corrects
the problem:


replace       $cmd = $cmd."-p ";
with       $cmd = $cmd."-b $name ";


----------------------------------------------------------------------

>Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-09-05 09:52

Message:
Logged In: YES 
user_id=85809

The fix appears correct. The PHP interface was not updated
since the personal list implementation changed. However, I'd
prefer to leave it to Daniel as he may want to make use of
multiple personal lists and provide an entirely different
interface to this feature.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1552068&group_id=26091

[Refdb-devel] [ refdb-Bugs-1552068 ] Search in personal list does not work with the web interface

[SourceForge.net <no...@so...>]

Bugs item #1552068, was opened at 2006-09-04 18:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1552068&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface (example)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dominik (dreusser)
Assigned to: Nobody/Anonymous (nobody)
Summary: Search in personal list does not work with the web interface

Initial Comment:
When searching for records in the personal list from
the webinterface, no records are returned. The
following change in line 90 of refdbsearch.php corrects
the problem:


replace       $cmd = $cmd."-p ";
with       $cmd = $cmd."-b $name ";


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1552068&group_id=26091

[Refdb-devel] [ refdb-Bugs-1552020 ] :UR:!~ search does not return expected set

[SourceForge.net <no...@so...>]

Bugs item #1552020, was opened at 2006-09-04 16:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1552020&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: refdbd
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dominik (dreusser)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: :UR:!~ search does not return expected set

Initial Comment:
If searching for records that do not match a certain
string in their URL, I expect to get all records that
do not include this string in the URL, including
records with an empty URL. However, the query seems not
to return records with empty URL. The sql-string should
include "t_link.link_url!~'string' OR
ISNULL(t_link.link_url)". This might also apply to
other exclusive searches.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1552020&group_id=26091

Re: [Refdb-devel] DB_VERSION redux

[Markus H. <mar...@mh...>]

David Nebauer <dav...@sw...> was heard to say:

> The Debian package uses sqlite as the database backend and it does not,
> as I understand it, accepts any username and password.  All that is
> essential is the calling program have root access, which the package
> manager certainly does.
>

Oh, I'm sorry. I forgot about this. In this case it is indeed sufficient to run
refdbd with root access. I'll try to whip up a solution for 0.9.8.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-devel] DB_VERSION redux

[David N. <dav...@sw...>]

Hi Markus,
> Before I go into the details, I've got one question. Does the package
> postinstall script have access to the database admin username and
> password?

The Debian package uses sqlite as the database backend and it does not, 
as I understand it, accepts any username and password.  All that is 
essential is the calling program have root access, which the package 
manager certainly does.

I hope I've interpreted your question correctly.

Regards,
David.

Re: [Refdb-devel] DB_VERSION redux

[Markus H. <mar...@mh...>]

Hi David,

David Nebauer writes:
 > > An entirely different solution is to let refdbd handle the upgrades
 > > internally. refdbd would have to retain the ability to read old-style
 > > databases, save the data to temporary tables, alter the database
 > > schema, and write the data back into place.
 > 
 > Sounds like a brilliant idea and it gets my vote.
 > 

Before I go into the details, I've got one question. Does the package
postinstall script have access to the database admin username and
password?

I don't see a chance to let refdbd handle upgrades silently. To this
end you'd have to make sure the first connection after upgrading is
from the database admin account. This would be easy if the clients
were around - the postinstall script could send a ping to trigger the
upgrade. But as we've seen before it is not an option to rely on the
clients (at least not a *desirable* option).

What I could do is add a command-line switch to refdbd that lets it
run as sort of a one-time version checker. But I'd have to provide the
database superuser name and password to be able to upgrade the
database.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-devel] Docs failing to build

[David N. <dav...@sw...>]

Hi Markus,
> thanks for analyzing this weird problem. Will you follow up on this on
> the XML mailing list?

I started putting together a test case but got lost trying to reduce the 
complexity of the xsl files.  I found myself drowning in error messages 
and gave up.  It's working for refdb now and that's the main thing.

Regards,
David.

Re: [Refdb-devel] DB_VERSION redux

[David N. <dav...@sw...>]

Hi Markus,

>  > What this problem cries out for is a data conversion utility that ships 
>  > with the server package and can be called by pre- and/or post-install 
>  > scripts to upgrade all databases in-place and without user involvement.
>
> An entirely different solution is to let refdbd handle the upgrades
> internally. refdbd would have to retain the ability to read old-style
> databases, save the data to temporary tables, alter the database
> schema, and write the data back into place.

Sounds like a brilliant idea and it gets my vote.

> This is doable, although
> it requires quite a bit of coding. It may turn out to be a nightmare
> to maintain in the long run, as I'd have to test an increasing number
> of combinations (1->2, then 1->3 and 2->3, then 1->4, 2->4, 3->4 and
> so on) before releasing a new backwards-incompatible version.

I may be a naive, but why not have a translation routine for each
increment in database version, i.e., from 1 to 2, 2 to 3, and so on.  If
refdbd found it necessary to translate from version 1 to 4, it would
sequentially call the translation routines 1 to 2, 2 to 3 and 3 to 4.
It may not be the most elegant solution, but it has the virtues that:
- number of translation routines increases geometrically with version
numbers rather than exponentially,
- it is easier to code and maintain, and
- it's hidden from the user anyway so who cares?

The longer translation time for a large version number jump is not
significant.  It is a one-off cost and most people regularly update
their systems so they will only ever jump a single version number at a time.

> I guess it is not Debian-like to abort the installation if the
> database needs to be updated and ask the user to backup his data?

That is precisely the solution I used in the previous unitary refdb
package.  The problem with using it now is it only stops the server
package upgrading.  If the clients package is installed on the same
machine it *will* be upgraded.  The danger then is the clients and
server will be at different versions.  I assumed this would be a *BAD
THING*.  I wasn't sure the backup script, which uses refdba and refdbc,
would work if the clients were from the new package (and therefore new
database version) while the server was from the old package (and
therefore old database version).  Was I right to be worried?  If you can
guarantee the clients will always work in this situation then I can use
the previous solution of aborting the server upgrade so the user can
backup the databases before upgrading again.

I'm not sure whether such a solution is "Debian-like".  I do know it's
goddamn ugly.  Rather than gracefully upgrading the databases in situ,
the entire update (which likely involved many packages other than refdb)
fails with an error message.  This forces the user to trace back to find
the package that failed to upgrade and try to figure out the reason why.

Even if this solution is usable, I would urge you to consider it an
interim one and to implement the translation schema you postulated earlier.

Regards,
David.

Re: [Refdb-devel] Docs failing to build

[Markus H. <mar...@mh...>]

Hi David,

thanks for analyzing this weird problem. Will you follow up on this on
the XML mailing list? As I can't reproduce this problem here, I don't
want to report it myself as I couldn't run any suggested debug
tests. I'd be happy though to help writing a description of the
problem. In any case, DocBook and xsltproc are a likely
combination for building the documentation of an autotools-based
software. It is always annoying to see an installation fail because
the docs won't build properly.

regards,
Markus

David Nebauer writes:
 > Hi Markus,
 > >> More specifically, the error is caused by the inclusion of '../doc/' in
 > >> specifying the stylesheet.  It makes no difference whether included or
 > >> not in the source xml file name.
 > 
 > As so often happens, this problem has self-corrected after another 
 > system update.  I have no idea what the offending package was, nor the 
 > underlying cause.
 > 

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[Refdb-devel] DB_VERSION redux

[Markus H. <mar...@mh...>]

Hi David,

David Nebauer writes:
 > Hi Markus,
 > 
 > The change in database version in svn has exposed some problems.  First, 
 > use of refdba and refdbc has not caused /var/lib/refdb/db/DB_VERSION to 
 > increment from 1 to 2.  I've restarted the refdbd daemon and run clients 
 > as root but it stays at '1'.  I haven't yet investigated log messages.
 > 

They should be informative. Just grep for "version file". Let me know
what you find. The upgrade did work on my box. DB_VERSION contains a
'2' here without any manual intervention.

Anyway, we had to bump into this problem eventually. I prefer this to
happen now (between prereleases) than during a release.
 
 > What this problem cries out for is a data conversion utility that ships 
 > with the server package and can be called by pre- and/or post-install 
 > scripts to upgrade all databases in-place and without user involvement.  
 > A "poor man's" approach would be to move the backup and restore scripts 
 > from client package to server package.  The server package would also 
 > need renamed copies of the refdba and refdbc clients (as they are called 
 > by the backup and restore scripts).
 > 

This is not much different from saying "the server package depends on
the client package". Maybe we have to face it for the moment.

An entirely different solution is to let refdbd handle the upgrades
internally. refdbd would have to retain the ability to read old-style
databases, save the data to temporary tables, alter the database
schema, and write the data back into place. This is doable, although
it requires quite a bit of coding. It may turn out to be a nightmare
to maintain in the long run, as I'd have to test an increasing number
of combinations (1->2, then 1->3 and 2->3, then 1->4, 2->4, 3->4 and
so on) before releasing a new backwards-incompatible version.


 > When DB_VERSION was first added to refdb you declared it to be a "slimy 
 > hack".  Perhaps now is a good time to implement a more robust solution.
 > 

Yup. Lesson learned. Sooner or later, all hacks will start to haunt
you.

 > Having fixed the documentation problems, I am now reluctant to post a 
 > new svn debian package until this "migration" issue is resolved.
 > 

I guess it is not Debian-like to abort the installation if the
database needs to be updated and ask the user to backup his data?
Instead of upgrading you'd have to deinstall the old package and
reinstall the new one, followed by restoring the data. The problem is
that I badly need some feedback about the new citekey citation style
which only works in the SVN version...

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[Refdb-devel] DB_VERSION redux

[David N. <dav...@sw...>]

Hi Markus,

The change in database version in svn has exposed some problems.  First, 
use of refdba and refdbc has not caused /var/lib/refdb/db/DB_VERSION to 
increment from 1 to 2.  I've restarted the refdbd daemon and run clients 
as root but it stays at '1'.  I haven't yet investigated log messages.

The second problem is more complex.  It has to do with how the packaging 
system handles an upgrade in database version.  You may recall the 
unitary refdb package handled this by having the pre-install script 
compare database versions of new package and existing package.  If the 
new database version was higher, then the user was urged to abort the 
upgrade and backup all data.  The backup and restore scripts could 
assist.  The upgrade abort was achieved by having the pre-install script 
exit with a non-zero status.  This forced the package manager to abort 
the upgrade.

Now refdb is split into clients and server packages.  Only the server 
package has the version-checking machinery.  If both clients and server 
packages are running on the same machine, the clients package updates 
but the server package update may be aborted.  This may result in the 
application being unable to access *any* reference data.

The most obvious solution is to use the pre-install script to force a 
data backup (by, say, refdb-backup) and use the post-install script to 
restore the data (by, say, refdb-restore).  The problem is the server 
package may be running on a computer without the clients package.  The 
backup and restore scripts require the refdba and refdbc clients 
supplied by the clients package.  In fact, since both clients are used 
in backing up and restoring reference data, neither operation can be 
done on server-managed data in the absence of the clients package.  The 
relevant client executables cannot be packaged into both packages under 
the same names as this is forbidden by all package managers.  Forcing 
the server package to be dependent on the clients package would, 
however, defeat the purpose of splitting refdb into multiple packages in 
the first place.

What this problem cries out for is a data conversion utility that ships 
with the server package and can be called by pre- and/or post-install 
scripts to upgrade all databases in-place and without user involvement.  
A "poor man's" approach would be to move the backup and restore scripts 
from client package to server package.  The server package would also 
need renamed copies of the refdba and refdbc clients (as they are called 
by the backup and restore scripts).

When DB_VERSION was first added to refdb you declared it to be a "slimy 
hack".  Perhaps now is a good time to implement a more robust solution.

Having fixed the documentation problems, I am now reluctant to post a 
new svn debian package until this "migration" issue is resolved.

Regards,
David.

Re: [Refdb-devel] Docs failing to build

[David N. <dav...@sw...>]

Hi Markus,
>> More specifically, the error is caused by the inclusion of '../doc/' in
>> specifying the stylesheet.  It makes no difference whether included or
>> not in the source xml file name.

As so often happens, this problem has self-corrected after another 
system update.  I have no idea what the offending package was, nor the 
underlying cause.

For what it's worth, here is the current situation regarding 
stylesheets.  You will see I experimented with putting all stylesheets 
in the 'doc' directory rather than the 'include' subdirectory.  This 
makes a difference.

TOPSRCDIR?  USE SUBDIR?       RESULT
----------  -----------       ------
Yes         Yes          -->  SUCCEEDED   [../doc/include/manual-fo.xsl]
Yes         No           -->  FAILED      [../doc/manual-fo.xsl]
No          Yes          -->  FAILED      [include/manual-fo.xsl]
No          No           -->  SUCCEEDED   [manual-fo.xsl]

The results are perplexing.  Using '../doc/' as part of the stylesheet 
filepath works when stylesheets are in a subdirectory but not when they 
are in the current directory.  If you remove the '../doc/' construct the 
situation reverses: success when stylesheets are in the current 
directory but failure when they are in the subdirectory.  Passing 
strange indeed.

In any event, the command used in the refdb makefile happens to be of a 
form now recognised by xsltproc -- so we are in the clear for now.  If, 
however, a problem building the manual should arise in the future it 
will be worth remembering the fragility of xsltproc's command line.

Regards,
David.

[Refdb-devel] [ refdb-Bugs-1550516 ] Import of multiple files does not resume correctly after err

[SourceForge.net <no...@so...>]

Bugs item #1550516, was opened at 2006-09-01 15:20
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1550516&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Dominik (dreusser)
Assigned to: Nobody/Anonymous (nobody)
Summary: Import of multiple files does not resume correctly after err

Initial Comment:
SELECT VERSION()
BEGIN
LOCK TABLES t_refdb WRITE, t_author WRITE, t_keyword
WRITE, t_periodical WRITE, t_user WRITE, t_xauthor
WRITE, t_xkeyword WRITE, t_xuser WRITE, t_note WRITE,
t_xnote WRITE, t_link WRITE, t_xlink WRITE,
refdb.t_journal_words WRITE
INSERT INTO t_refdb (refdb_type,refdb_citekey) VALUES
('DUMMY','DUMMYaare5779')
SELECT user_id FROM t_user WHERE user_name='dominik'
INSERT INTO t_xuser (user_id, refdb_id) VALUES (1,2349)
SELECT refdb_id, refdb_citekey FROM t_refdb WHERE
refdb_id=2349
SELECT note_id, note_user_id from t_note WHERE
note_key='dominik-dominik'
SELECT refdb_id from t_refdb WHERE
refdb_citekey='DUMMYaare5779'
SELECT xnote_id FROM t_xnote WHERE note_id=1 AND
xnote_type='REFERENCE' AND xref_id=2349
INSERT INTO t_xnote (note_id, xref_id, xnote_type)
VALUES (1, 2349, 'REFERENCE')
unknown token:TY  - JOUR<<-17:-69:-65:84:89:32<<

SELECT author_id FROM t_author WHERE
author_name='Abdulla,F.A.'
INSERT INTO t_xauthor (author_id, refdb_id,
xauthor_type, xauthor_position, xauthor_role) VALUES
(3854, 2349, 'primary', 0, '')
SELECT author_id FROM t_author WHERE
author_name='Lettenmaier,D.P.'
INSERT INTO t_xauthor (author_id, refdb_id,
xauthor_type, xauthor_position, xauthor_role) VALUES
(2509, 2349, 'primary', 1, '')
SELECT name FROM refdb.t_journal_words WHERE name='J.'
SELECT name FROM refdb.t_journal_words WHERE name='HYDROL.'
UPDATE t_xuser SET xuser_notes='bd swurve' WHERE
refdb_id=2349 AND user_id=1
SELECT link_id FROM t_link WHERE
link_url='http://www.sciencedirect.com/science/article/B6V6C-3T7JKM3-13/1/6f09c19663404326d3bf427ccf0b30da'
INSERT INTO t_xlink (link_id, xref_id, xlink_type,
xlink_source) VALUES (1002, 2349, 'URL', 'REFERENCE')
SELECT periodical_id FROM t_periodical WHERE
periodical_name='Journal of Hydrology'
SELECT periodical_name, periodical_abbrev,
periodical_custabbrev1, periodical_custabbrev2 FROM
t_periodical WHERE periodical_id=9
UPDATE t_periodical SET periodical_name='Journal of
Hydrology' WHERE periodical_id = 9
UPDATE t_periodical SET periodical_abbrev='J. Hydrol.'
WHERE periodical_id = 9
UPDATE t_refdb SET refdb_periodical_id=9 WHERE refdb_id
= 2349
UPDATE t_xuser SET xuser_reprint = 'NOT IN FILE' WHERE
refdb_id=2349 AND user_id=1
outbuffer went to: Abdulla<<
SELECT refdb_id FROM t_refdb WHERE
refdb_citekey='Abdulla1997'
406:1:Abdulla1997

UPDATE t_refdb SET refdb_pubyear=1997, refdb_secyear=0,
refdb_pyother_info='/10/01/', refdb_secother_info=NULL,
refdb_citekey='Abdulla1997', refdb_user1=NULL,
refdb_user2='schaeffli', refdb_user3=NULL,
refdb_user4=NULL, refdb_user5=NULL, refdb_misc1=NULL,
refdb_misc2=NULL, refdb_misc3=NULL, refdb_issn=NULL,
refdb_issue='1-4', refdb_publisher=NULL,
refdb_city=NULL, refdb_volume='197',
refdb_endpage='257', refdb_startpage='230',
refdb_type=GEN, refdb_abstract='A methodology for
developing regional parameter estimation equations,
designed for application to continental scale river
basins, is described. The approach, which is applied to
the two-layer Variable Infiltration Capacity (VIC-2L)
land surface hydrologic model, uses a set of 34
unregulated calibration or \"training\" catchments
(drainage areas 102-104&nbsp;km2) distributed
throughout the Arkansas-Red River basin of the south
central U.S. For each of these catchments, parameters
were determined by: a) prior estimation of two of the
model parameters (saturated hydraulic conductivity and
pore size distribution index) from the U.S. Soil
Conservation Service State Soil Geographic Data Base
(STATSGO) data base; and b) estimation of the remaining
seven parameters via a search procedure that minimizes
the sum of squares of differences between predicted and
observed streamflow. The catchment parameters were then
related to 11 ancillary distributed land surface
characteristics extracted from STATSGO, and 17
variables derived from station meteorological data. The
seven regression equations explained from 54 to 76% of
the variance of the parameters. The most frequently
occurring ancillary variables were the average
permeability, saturated hydraulic conductivity, and SCS
hydrologic Group B (typically soils with moderately
high infiltration rates) fraction derived from STATSGO,
and the average temperature and standard deviation of
fall precipitation. The method was tested by comparing
simulations using the regional (regression equation)
parameters for six unregulated catchments not in the
parameter estimation set. The model performance using
the regional parameters was quite good for most of the
calibration and validation catchments, which were humid
and semi-humid. The model did not perform as well for
the smaller number of arid to semi-arid catchments.',
refdb_title='Development of regional parameter
estimation equations for a macroscale hydrologic model'
WHERE refdb_id=2349
1054: Unknown column 'GEN' in 'field list'
inserting reference data failed
COMMIT
ROLLBACK
UNLOCK TABLES
failed processing dataset
BEGIN
LOCK TABLES t_refdb WRITE, t_author WRITE, t_keyword
WRITE, t_periodical WRITE, t_user WRITE, t_xauthor
WRITE, t_xkeyword WRITE, t_xuser WRITE, t_note WRITE,
t_xnote WRITE, t_link WRITE, t_xlink WRITE,
refdb.t_journal_words WRITE
INSERT INTO t_refdb (refdb_type,refdb_citekey) VALUES
('DUMMY','DUMMYaare5779')
1062: Duplicate entry 'DUMMYaare5779' for key 2
inserting reference data failed
ROLLBACK
UNLOCK TABLES
failed processing dataset
BEGIN
LOCK TABLES t_refdb WRITE, t_author WRITE, t_keyword
WRITE, t_periodical WRITE, t_user WRITE, t_xauthor
WRITE, t_xkeyword WRITE, t_xuser WRITE, t_note WRITE,
t_xnote WRITE, t_link WRITE, t_xlink WRITE,
refdb.t_journal_words WRITE
INSERT INTO t_refdb (refdb_type,refdb_citekey) VALUES
('DUMMY','DUMMYaare5779')
1062: Duplicate entry 'DUMMYaare5779' for key 2
inserting reference data failed
ROLLBACK
UNLOCK TABLES
failed processing dataset

and so on...

----------------------------------------------------------------------

>Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-09-02 02:28

Message:
Logged In: YES 
user_id=85809

This error report exposes two unrelated bugs:

1) the default type "GEN" which is used if the dataset
erroneously lacks a type info needs to be quoted

2) in case of an error the transaction was committed before
a rollback was attempted

Both problems are fixed in the current SVN version (revision
159).


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1550516&group_id=26091

[Refdb-devel] [ refdb-Bugs-1550514 ] Trouble while importing chapters

[SourceForge.net <no...@so...>]

Bugs item #1550514, was opened at 2006-09-01 15:15
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1550514&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: refdbd
Group: None
Status: Open
>Resolution: Works For Me
Priority: 5
Submitted By: Dominik (dreusser)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: Trouble while importing chapters

Initial Comment:
Queries are not assembled correctly (cutting of either
the refdb_title or redb_booktitile) while importing
chapters from a file with multiple records. For some
reason, writing the records to a seprate file and
importing from there works for some records. I attached
a file with example records that failed.


Example 1
----------
UPDATE t_refdb SET refdb_pubyear=2003, refdb_secyear=0,
refdb_pyother_info='///', refdb_secother_info=NULL,
refdb_citekey='Bardsley2003a', refdb_user1=NULL,
refdb_user2='schaeffli', refdb_user3=NULL,
refdb_user4=NULL, refdb_user5=NULL, refdb_misc1=NULL,
refdb_misc2=NULL, refdb_misc3=NULL, refdb_issn=NULL,
refdb_issue=NULL, refdb_publisher='IAHS Publication no.
281', refdb_city='Wallingford, Oxfordshire UK',
refdb_volume=NULL, refdb_endpage='74',
refdb_startpage='67', refdb_type='CHAP',
refdb_booktitle='Water resources systems - hydrological
risk, management and development  (Proceedings of an
international symposium the XXIII General Assembly of
the International Union of Geodesy and Geophysics, at
Sapporo, Japan, from 30 June to 11 July 2003)',
refdb_title='An approach to creating lumped-parameter
rainfall-runoff models for drainage basins experiencing
envrionemental WHERE refdb_id=2393
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 ''An approach to
creating lumped-parameter rainfall-runoff models
inserting reference data failed

Example 2
---------
UPDATE t_refdb SET refdb_pubyear=1998, refdb_secyear=0,
refdb_pyother_info='///', refdb_secother_info=NULL,
refdb_citekey='Aizen1998', refdb_user1=NULL,
refdb_user2='schaeffli', refdb_user3=NULL,
refdb_user4=NULL, refdb_user5=NULL, refdb_misc1=NULL,
refdb_misc2=NULL, refdb_misc3=NULL, refdb_issn=NULL,
refdb_issue=NULL, refdb_publisher='IAHS Publication No.
248', refdb_city='Wallingford, Oxfordshire UK',
refdb_volume=NULL, refdb_endpage='198',
refdb_startpage='191', refdb_type='CHAP',
refdb_booktitle='Hydrology, Water Resources and Ecology
in Headwaters (P, refdb_title='Estimation of glacial
runoff to the Tarim River, central Tien Shan' WHERE
refdb_id=2352
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 'Estimation of glacial
runoff to the Tarim River, central Tien Sh
inserting reference data failed

refdb-bug:
Linux aare 2.6.17-1-686 #1 SMP Sat Jul 29 15:32:47 UTC
2006 i686 GNU/Linux
RefDB binaries and scripts in the path:
/usr/bin/refdbd
/usr/bin/refdba
/usr/bin/refdbc
/usr/bin/refdbib
/usr/bin/bib2ris
and their version numbers:
refdbd 0.9.8-pre2
refdba 0.9.8-pre2
refdbc 0.9.8-pre2
refdbib 0.9.8-pre2
/usr/bin/refdb-bug: line 41: nmed2ris: command not found
bib2ris 0.9.8-pre2
DSSSL engines in the path:
and their version numbers:

$REFDBLIB is /usr/share/refdb
global refdbd config file:
refdblib /usr/share/refdb
serverip        localhost
dbsport 3306
dbserver        mysql
dbpath          /var/lib/refdb/db
port    9734
logfile /var/log/refdbd.log
logdest file
loglevel info
pidfile         /var/run/refdbd.pid
remoteadmin f
remoteconnect f
keep_pnames t
keyword_scan t
db_encoding
in_encoding     UTF-8

global refdba config file:
serverip        127.0.0.1
port    9734
pager   less
username        joeuser
passwd  <protected>
logdest file
loglevel info
logfile /var/log/refdba.log

global refdbc config file:
serverip        127.0.0.1
port    9734
pager   less
username        joeuser
passwd  <protected>
logdest file
loglevel info
logfile /var/log/refdbc.log
cssurl /usr/share/refdb/css/refdb.css
fromencoding UTF-8
toencoding UTF-8

global refdbc config file (cgi):

global refdbib config file:

global nmed2ris config file:

global bib2ris config file:

$HOME is /home/dreusser
user refdba config file:

user refdba config file (hidden):
serverip        127.0.0.1
username        root
passwd          <protected>
pager           less
toencoding      ISO-8859-1
fromencoding    ISO-8859-1

user refdbc config file:

user refdbc config file (hidden):
serverip        127.0.0.1
username        dominik
passwd          <protected>
defaultdb       hykli
pager           less
toencoding      ISO-8859-1
fromencoding    ISO-8859-1

user refdbib config file:

user refdbib config file (hidden):
serverip        127.0.0.1
username        dominik
passwd          <protected>
defaultdb       refdb_test
pager           less
toencoding      ISO-8859-1

user nmed2ris config file:

user nmed2ris config file (hidden):

user bib2ris config file:

user bib2ris config file (hidden):
logfile bib2ris.log
logdest 2
loglevel 7
nsf_abstract N2
nsf_url UR
nsf_url2 UR
nsf_pdf UR
nsf_keywords KW
nsf_owner U2
nsf_comment U3
nsf_issn SN


----------------------------------------------------------------------

>Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-09-02 01:36

Message:
Logged In: YES 
user_id=85809

I've never encountered problems like this one on any of my
installations. To make sure I've installed 0.9.8-pre3 (the
only difference to pre2 is the inclusion of two headers in
refdbdgetref.c to avoid compiler errors) on a pristine
Debian 3.1 box. I can import your test data without any
problems.

I'll post a message to the refdb-users list to see whether
anyone else has seen this. Unless we can pin down the
environment or the circumstances that lead to this problem,
I'll not be able to fix it.


----------------------------------------------------------------------

Comment By: Dominik (dreusser)
Date: 2006-09-01 15:33

Message:
Logged In: YES 
user_id=1572139

It is not just while adding chapters. But I haven't found
out when addref fails exactly..

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1550514&group_id=26091

[Refdb-devel] [ refdb-Bugs-1550514 ] Trouble while importing chapters

[SourceForge.net <no...@so...>]

Bugs item #1550514, was opened at 2006-09-01 15:15
Message generated for change (Comment added) made by dreusser
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1550514&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: refdbd
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dominik (dreusser)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: Trouble while importing chapters

Initial Comment:
Queries are not assembled correctly (cutting of either
the refdb_title or redb_booktitile) while importing
chapters from a file with multiple records. For some
reason, writing the records to a seprate file and
importing from there works for some records. I attached
a file with example records that failed.


Example 1
----------
UPDATE t_refdb SET refdb_pubyear=2003, refdb_secyear=0,
refdb_pyother_info='///', refdb_secother_info=NULL,
refdb_citekey='Bardsley2003a', refdb_user1=NULL,
refdb_user2='schaeffli', refdb_user3=NULL,
refdb_user4=NULL, refdb_user5=NULL, refdb_misc1=NULL,
refdb_misc2=NULL, refdb_misc3=NULL, refdb_issn=NULL,
refdb_issue=NULL, refdb_publisher='IAHS Publication no.
281', refdb_city='Wallingford, Oxfordshire UK',
refdb_volume=NULL, refdb_endpage='74',
refdb_startpage='67', refdb_type='CHAP',
refdb_booktitle='Water resources systems - hydrological
risk, management and development  (Proceedings of an
international symposium the XXIII General Assembly of
the International Union of Geodesy and Geophysics, at
Sapporo, Japan, from 30 June to 11 July 2003)',
refdb_title='An approach to creating lumped-parameter
rainfall-runoff models for drainage basins experiencing
envrionemental WHERE refdb_id=2393
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 ''An approach to
creating lumped-parameter rainfall-runoff models
inserting reference data failed

Example 2
---------
UPDATE t_refdb SET refdb_pubyear=1998, refdb_secyear=0,
refdb_pyother_info='///', refdb_secother_info=NULL,
refdb_citekey='Aizen1998', refdb_user1=NULL,
refdb_user2='schaeffli', refdb_user3=NULL,
refdb_user4=NULL, refdb_user5=NULL, refdb_misc1=NULL,
refdb_misc2=NULL, refdb_misc3=NULL, refdb_issn=NULL,
refdb_issue=NULL, refdb_publisher='IAHS Publication No.
248', refdb_city='Wallingford, Oxfordshire UK',
refdb_volume=NULL, refdb_endpage='198',
refdb_startpage='191', refdb_type='CHAP',
refdb_booktitle='Hydrology, Water Resources and Ecology
in Headwaters (P, refdb_title='Estimation of glacial
runoff to the Tarim River, central Tien Shan' WHERE
refdb_id=2352
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 'Estimation of glacial
runoff to the Tarim River, central Tien Sh
inserting reference data failed

refdb-bug:
Linux aare 2.6.17-1-686 #1 SMP Sat Jul 29 15:32:47 UTC
2006 i686 GNU/Linux
RefDB binaries and scripts in the path:
/usr/bin/refdbd
/usr/bin/refdba
/usr/bin/refdbc
/usr/bin/refdbib
/usr/bin/bib2ris
and their version numbers:
refdbd 0.9.8-pre2
refdba 0.9.8-pre2
refdbc 0.9.8-pre2
refdbib 0.9.8-pre2
/usr/bin/refdb-bug: line 41: nmed2ris: command not found
bib2ris 0.9.8-pre2
DSSSL engines in the path:
and their version numbers:

$REFDBLIB is /usr/share/refdb
global refdbd config file:
refdblib /usr/share/refdb
serverip        localhost
dbsport 3306
dbserver        mysql
dbpath          /var/lib/refdb/db
port    9734
logfile /var/log/refdbd.log
logdest file
loglevel info
pidfile         /var/run/refdbd.pid
remoteadmin f
remoteconnect f
keep_pnames t
keyword_scan t
db_encoding
in_encoding     UTF-8

global refdba config file:
serverip        127.0.0.1
port    9734
pager   less
username        joeuser
passwd  <protected>
logdest file
loglevel info
logfile /var/log/refdba.log

global refdbc config file:
serverip        127.0.0.1
port    9734
pager   less
username        joeuser
passwd  <protected>
logdest file
loglevel info
logfile /var/log/refdbc.log
cssurl /usr/share/refdb/css/refdb.css
fromencoding UTF-8
toencoding UTF-8

global refdbc config file (cgi):

global refdbib config file:

global nmed2ris config file:

global bib2ris config file:

$HOME is /home/dreusser
user refdba config file:

user refdba config file (hidden):
serverip        127.0.0.1
username        root
passwd          <protected>
pager           less
toencoding      ISO-8859-1
fromencoding    ISO-8859-1

user refdbc config file:

user refdbc config file (hidden):
serverip        127.0.0.1
username        dominik
passwd          <protected>
defaultdb       hykli
pager           less
toencoding      ISO-8859-1
fromencoding    ISO-8859-1

user refdbib config file:

user refdbib config file (hidden):
serverip        127.0.0.1
username        dominik
passwd          <protected>
defaultdb       refdb_test
pager           less
toencoding      ISO-8859-1

user nmed2ris config file:

user nmed2ris config file (hidden):

user bib2ris config file:

user bib2ris config file (hidden):
logfile bib2ris.log
logdest 2
loglevel 7
nsf_abstract N2
nsf_url UR
nsf_url2 UR
nsf_pdf UR
nsf_keywords KW
nsf_owner U2
nsf_comment U3
nsf_issn SN


----------------------------------------------------------------------

>Comment By: Dominik (dreusser)
Date: 2006-09-01 15:33

Message:
Logged In: YES 
user_id=1572139

It is not just while adding chapters. But I haven't found
out when addref fails exactly..

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1550514&group_id=26091

[Refdb-devel] [ refdb-Bugs-1550516 ] Import of multiple files does not resume correctly after err

[SourceForge.net <no...@so...>]

Bugs item #1550516, was opened at 2006-09-01 15:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1550516&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dominik (dreusser)
Assigned to: Nobody/Anonymous (nobody)
Summary: Import of multiple files does not resume correctly after err

Initial Comment:
SELECT VERSION()
BEGIN
LOCK TABLES t_refdb WRITE, t_author WRITE, t_keyword
WRITE, t_periodical WRITE, t_user WRITE, t_xauthor
WRITE, t_xkeyword WRITE, t_xuser WRITE, t_note WRITE,
t_xnote WRITE, t_link WRITE, t_xlink WRITE,
refdb.t_journal_words WRITE
INSERT INTO t_refdb (refdb_type,refdb_citekey) VALUES
('DUMMY','DUMMYaare5779')
SELECT user_id FROM t_user WHERE user_name='dominik'
INSERT INTO t_xuser (user_id, refdb_id) VALUES (1,2349)
SELECT refdb_id, refdb_citekey FROM t_refdb WHERE
refdb_id=2349
SELECT note_id, note_user_id from t_note WHERE
note_key='dominik-dominik'
SELECT refdb_id from t_refdb WHERE
refdb_citekey='DUMMYaare5779'
SELECT xnote_id FROM t_xnote WHERE note_id=1 AND
xnote_type='REFERENCE' AND xref_id=2349
INSERT INTO t_xnote (note_id, xref_id, xnote_type)
VALUES (1, 2349, 'REFERENCE')
unknown token:TY  - JOUR<<-17:-69:-65:84:89:32<<

SELECT author_id FROM t_author WHERE
author_name='Abdulla,F.A.'
INSERT INTO t_xauthor (author_id, refdb_id,
xauthor_type, xauthor_position, xauthor_role) VALUES
(3854, 2349, 'primary', 0, '')
SELECT author_id FROM t_author WHERE
author_name='Lettenmaier,D.P.'
INSERT INTO t_xauthor (author_id, refdb_id,
xauthor_type, xauthor_position, xauthor_role) VALUES
(2509, 2349, 'primary', 1, '')
SELECT name FROM refdb.t_journal_words WHERE name='J.'
SELECT name FROM refdb.t_journal_words WHERE name='HYDROL.'
UPDATE t_xuser SET xuser_notes='bd swurve' WHERE
refdb_id=2349 AND user_id=1
SELECT link_id FROM t_link WHERE
link_url='http://www.sciencedirect.com/science/article/B6V6C-3T7JKM3-13/1/6f09c19663404326d3bf427ccf0b30da'
INSERT INTO t_xlink (link_id, xref_id, xlink_type,
xlink_source) VALUES (1002, 2349, 'URL', 'REFERENCE')
SELECT periodical_id FROM t_periodical WHERE
periodical_name='Journal of Hydrology'
SELECT periodical_name, periodical_abbrev,
periodical_custabbrev1, periodical_custabbrev2 FROM
t_periodical WHERE periodical_id=9
UPDATE t_periodical SET periodical_name='Journal of
Hydrology' WHERE periodical_id = 9
UPDATE t_periodical SET periodical_abbrev='J. Hydrol.'
WHERE periodical_id = 9
UPDATE t_refdb SET refdb_periodical_id=9 WHERE refdb_id
= 2349
UPDATE t_xuser SET xuser_reprint = 'NOT IN FILE' WHERE
refdb_id=2349 AND user_id=1
outbuffer went to: Abdulla<<
SELECT refdb_id FROM t_refdb WHERE
refdb_citekey='Abdulla1997'
406:1:Abdulla1997

UPDATE t_refdb SET refdb_pubyear=1997, refdb_secyear=0,
refdb_pyother_info='/10/01/', refdb_secother_info=NULL,
refdb_citekey='Abdulla1997', refdb_user1=NULL,
refdb_user2='schaeffli', refdb_user3=NULL,
refdb_user4=NULL, refdb_user5=NULL, refdb_misc1=NULL,
refdb_misc2=NULL, refdb_misc3=NULL, refdb_issn=NULL,
refdb_issue='1-4', refdb_publisher=NULL,
refdb_city=NULL, refdb_volume='197',
refdb_endpage='257', refdb_startpage='230',
refdb_type=GEN, refdb_abstract='A methodology for
developing regional parameter estimation equations,
designed for application to continental scale river
basins, is described. The approach, which is applied to
the two-layer Variable Infiltration Capacity (VIC-2L)
land surface hydrologic model, uses a set of 34
unregulated calibration or \"training\" catchments
(drainage areas 102-104&nbsp;km2) distributed
throughout the Arkansas-Red River basin of the south
central U.S. For each of these catchments, parameters
were determined by: a) prior estimation of two of the
model parameters (saturated hydraulic conductivity and
pore size distribution index) from the U.S. Soil
Conservation Service State Soil Geographic Data Base
(STATSGO) data base; and b) estimation of the remaining
seven parameters via a search procedure that minimizes
the sum of squares of differences between predicted and
observed streamflow. The catchment parameters were then
related to 11 ancillary distributed land surface
characteristics extracted from STATSGO, and 17
variables derived from station meteorological data. The
seven regression equations explained from 54 to 76% of
the variance of the parameters. The most frequently
occurring ancillary variables were the average
permeability, saturated hydraulic conductivity, and SCS
hydrologic Group B (typically soils with moderately
high infiltration rates) fraction derived from STATSGO,
and the average temperature and standard deviation of
fall precipitation. The method was tested by comparing
simulations using the regional (regression equation)
parameters for six unregulated catchments not in the
parameter estimation set. The model performance using
the regional parameters was quite good for most of the
calibration and validation catchments, which were humid
and semi-humid. The model did not perform as well for
the smaller number of arid to semi-arid catchments.',
refdb_title='Development of regional parameter
estimation equations for a macroscale hydrologic model'
WHERE refdb_id=2349
1054: Unknown column 'GEN' in 'field list'
inserting reference data failed
COMMIT
ROLLBACK
UNLOCK TABLES
failed processing dataset
BEGIN
LOCK TABLES t_refdb WRITE, t_author WRITE, t_keyword
WRITE, t_periodical WRITE, t_user WRITE, t_xauthor
WRITE, t_xkeyword WRITE, t_xuser WRITE, t_note WRITE,
t_xnote WRITE, t_link WRITE, t_xlink WRITE,
refdb.t_journal_words WRITE
INSERT INTO t_refdb (refdb_type,refdb_citekey) VALUES
('DUMMY','DUMMYaare5779')
1062: Duplicate entry 'DUMMYaare5779' for key 2
inserting reference data failed
ROLLBACK
UNLOCK TABLES
failed processing dataset
BEGIN
LOCK TABLES t_refdb WRITE, t_author WRITE, t_keyword
WRITE, t_periodical WRITE, t_user WRITE, t_xauthor
WRITE, t_xkeyword WRITE, t_xuser WRITE, t_note WRITE,
t_xnote WRITE, t_link WRITE, t_xlink WRITE,
refdb.t_journal_words WRITE
INSERT INTO t_refdb (refdb_type,refdb_citekey) VALUES
('DUMMY','DUMMYaare5779')
1062: Duplicate entry 'DUMMYaare5779' for key 2
inserting reference data failed
ROLLBACK
UNLOCK TABLES
failed processing dataset

and so on...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1550516&group_id=26091

[Refdb-devel] [ refdb-Bugs-1550514 ] Trouble while importing chapters

[SourceForge.net <no...@so...>]

Bugs item #1550514, was opened at 2006-09-01 15:15
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1550514&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: refdbd
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dominik (dreusser)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: Trouble while importing chapters

Initial Comment:
Queries are not assembled correctly (cutting of either
the refdb_title or redb_booktitile) while importing
chapters from a file with multiple records. For some
reason, writing the records to a seprate file and
importing from there works for some records. I attached
a file with example records that failed.


Example 1
----------
UPDATE t_refdb SET refdb_pubyear=2003, refdb_secyear=0,
refdb_pyother_info='///', refdb_secother_info=NULL,
refdb_citekey='Bardsley2003a', refdb_user1=NULL,
refdb_user2='schaeffli', refdb_user3=NULL,
refdb_user4=NULL, refdb_user5=NULL, refdb_misc1=NULL,
refdb_misc2=NULL, refdb_misc3=NULL, refdb_issn=NULL,
refdb_issue=NULL, refdb_publisher='IAHS Publication no.
281', refdb_city='Wallingford, Oxfordshire UK',
refdb_volume=NULL, refdb_endpage='74',
refdb_startpage='67', refdb_type='CHAP',
refdb_booktitle='Water resources systems - hydrological
risk, management and development  (Proceedings of an
international symposium the XXIII General Assembly of
the International Union of Geodesy and Geophysics, at
Sapporo, Japan, from 30 June to 11 July 2003)',
refdb_title='An approach to creating lumped-parameter
rainfall-runoff models for drainage basins experiencing
envrionemental WHERE refdb_id=2393
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 ''An approach to
creating lumped-parameter rainfall-runoff models
inserting reference data failed

Example 2
---------
UPDATE t_refdb SET refdb_pubyear=1998, refdb_secyear=0,
refdb_pyother_info='///', refdb_secother_info=NULL,
refdb_citekey='Aizen1998', refdb_user1=NULL,
refdb_user2='schaeffli', refdb_user3=NULL,
refdb_user4=NULL, refdb_user5=NULL, refdb_misc1=NULL,
refdb_misc2=NULL, refdb_misc3=NULL, refdb_issn=NULL,
refdb_issue=NULL, refdb_publisher='IAHS Publication No.
248', refdb_city='Wallingford, Oxfordshire UK',
refdb_volume=NULL, refdb_endpage='198',
refdb_startpage='191', refdb_type='CHAP',
refdb_booktitle='Hydrology, Water Resources and Ecology
in Headwaters (P, refdb_title='Estimation of glacial
runoff to the Tarim River, central Tien Shan' WHERE
refdb_id=2352
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 'Estimation of glacial
runoff to the Tarim River, central Tien Sh
inserting reference data failed

refdb-bug:
Linux aare 2.6.17-1-686 #1 SMP Sat Jul 29 15:32:47 UTC
2006 i686 GNU/Linux
RefDB binaries and scripts in the path:
/usr/bin/refdbd
/usr/bin/refdba
/usr/bin/refdbc
/usr/bin/refdbib
/usr/bin/bib2ris
and their version numbers:
refdbd 0.9.8-pre2
refdba 0.9.8-pre2
refdbc 0.9.8-pre2
refdbib 0.9.8-pre2
/usr/bin/refdb-bug: line 41: nmed2ris: command not found
bib2ris 0.9.8-pre2
DSSSL engines in the path:
and their version numbers:

$REFDBLIB is /usr/share/refdb
global refdbd config file:
refdblib /usr/share/refdb
serverip        localhost
dbsport 3306
dbserver        mysql
dbpath          /var/lib/refdb/db
port    9734
logfile /var/log/refdbd.log
logdest file
loglevel info
pidfile         /var/run/refdbd.pid
remoteadmin f
remoteconnect f
keep_pnames t
keyword_scan t
db_encoding
in_encoding     UTF-8

global refdba config file:
serverip        127.0.0.1
port    9734
pager   less
username        joeuser
passwd  <protected>
logdest file
loglevel info
logfile /var/log/refdba.log

global refdbc config file:
serverip        127.0.0.1
port    9734
pager   less
username        joeuser
passwd  <protected>
logdest file
loglevel info
logfile /var/log/refdbc.log
cssurl /usr/share/refdb/css/refdb.css
fromencoding UTF-8
toencoding UTF-8

global refdbc config file (cgi):

global refdbib config file:

global nmed2ris config file:

global bib2ris config file:

$HOME is /home/dreusser
user refdba config file:

user refdba config file (hidden):
serverip        127.0.0.1
username        root
passwd          <protected>
pager           less
toencoding      ISO-8859-1
fromencoding    ISO-8859-1

user refdbc config file:

user refdbc config file (hidden):
serverip        127.0.0.1
username        dominik
passwd          <protected>
defaultdb       hykli
pager           less
toencoding      ISO-8859-1
fromencoding    ISO-8859-1

user refdbib config file:

user refdbib config file (hidden):
serverip        127.0.0.1
username        dominik
passwd          <protected>
defaultdb       refdb_test
pager           less
toencoding      ISO-8859-1

user nmed2ris config file:

user nmed2ris config file (hidden):

user bib2ris config file:

user bib2ris config file (hidden):
logfile bib2ris.log
logdest 2
loglevel 7
nsf_abstract N2
nsf_url UR
nsf_url2 UR
nsf_pdf UR
nsf_keywords KW
nsf_owner U2
nsf_comment U3
nsf_issn SN


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1550514&group_id=26091

Re: [Refdb-devel] Docs failing to build

[David N. <dav...@sw...>]

Hi Markus,

> More specifically, an xsltproc-on-Debian-specific bug. I've compared the patches
> that Debian and FreeBSD apply to the sources in their package and port,
> respectively. I don't see anything that would explain why things work ok on
> FreeBSD but not on Debian.
>
> One last chance: Can you verify with xsltproc --version that you invoke the
> right binary and the right libraries?

----------------------------------------------------------------------------
$ xsltproc --version
Using libxml 20626, libxslt 10117 and libexslt 813
xsltproc was compiled against libxml 20626, libxslt 10117 and libexslt 813
libxslt 10117 was compiled against libxml 20626
libexslt 813 was compiled against libxml 20626
$
----------------------------------------------------------------------------

Hope that helps.

Regards,
David.

Re: [Refdb-devel] Docs failing to build

[Markus H. <mar...@mh...>]

Hi,

David Nebauer <dav...@sw...>:

> More specifically, the error is caused by the inclusion of '../doc/' in
> specifying the stylesheet.  It makes no difference whether included or
> not in the source xml file name.

That is what I suspected. To the best of my knowledge the shell does not
canonicalize the path, i.e. the '../doc/<path>' is passed literally to
xsltproc. This works ok if the strings are used for regular "open()" or
"fopen()" calls. Therefore xsltproc finds both the XML file and the XSLT
stylesheet. However, to resolve the "xsl:include" in the stylesheet, an xslt
processor probably applies a different logic (the path could be an URL too). I
suspect that xsltproc expects a canonicalized path at that point.

> xmlstarlet uses the same underlying library ('libxslt1.1') but happily
> creates a viable FO file even when the offending '../doc/' is included.
> The following command works:
>
>     xmlstarlet tr --xinclude ../doc/include/manual-fo.xsl \
>     ../doc/refdb-manual.xml > refdb-manual.fo
>

This is even more confusing result. The "xsl:include" handling is certainly a
part of the library, not a part of the xsltproc application itself.

> It would appear to be an xsltproc-specific bug.
>

More specifically, an xsltproc-on-Debian-specific bug. I've compared the patches
that Debian and FreeBSD apply to the sources in their package and port,
respectively. I don't see anything that would explain why things work ok on
FreeBSD but not on Debian.

One last chance: Can you verify with xsltproc --version that you invoke the
right binary and the right libraries?

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-devel] Docs failing to build

[David N. <dav...@sw...>]

Hi Markus,
>> libxslt1.1: 1.1.17-3
>
> What is the version of your xsltproc package? I remember that Debian packages
> the binaries separately from the libraries. FWIW the FreeBSD port is also built
> from the libxslt 1.1.17 sources.

xsltproc: 1.1.17-3

> I have discovered the cause of the problem... but am no closer to
> understanding it.  It has to do with the /doc directory's xsltproc line.
>
> The makefile ends up executing the following command (excepting the
> backslash, of course):
>
>     xsltproc -o refdb-manual.fo --nonet --xinclude \
>     ../doc/include/manual-fo.xsl ../doc/refdb-manual.xml

More specifically, the error is caused by the inclusion of '../doc/' in 
specifying the stylesheet.  It makes no difference whether included or 
not in the source xml file name.

> OTOH if this is an xsltproc problem, you should create a simple testcase and
> post it to the XML mailing list (xm...@gn...). Do you have any other xslt
> processor installed to run a quick test?

xmlstarlet uses the same underlying library ('libxslt1.1') but happily 
creates a viable FO file even when the offending '../doc/' is included.  
The following command works:

    xmlstarlet tr --xinclude ../doc/include/manual-fo.xsl \
    ../doc/refdb-manual.xml > refdb-manual.fo

> A comparison with other xslt
> processors could show whether xsltproc is broken or whether I expected too much
> from it.

It would appear to be an xsltproc-specific bug.

Regards,
David.