Dear list,

I'm struggling to finish my last round of backups with Bacula 2.4.4,
which I care to do before migrating to the latest version. My problem is
simple to describe: with one of my (multiple, and otherwise working)
media pools, the director fails to find a usable volume for use with a
backup job (thus prompting for the labeling of a new one, which I really
want to avoid).

I've spent the evening going through debug output and part of the source
in src/dird/next_vol.c and src/cats/sql_find.c. Here is what seems like
the part relevant to the problem of what I'm witnessing in the director
debug output when I ask to run a job:

Washington-dir: sql_find.c:323-0 fnextvol=SELECT
MediaId,VolumeName,<snip> FROM Media WHERE PoolId=5 AND MediaType='LTO2
Ultrium' AND Enabled=1 AND VolStatus='Append'  ORDER BY LastWritten IS
NULL,LastWritten DESC,MediaId LIMIT 1
Washington-dir: sql_find.c:331-0 item=1 got=0

'got=0' means the query returned 0 rows. But copying and pasting the
exact same query in fact returns the expected result of the tape I'm
expecting. I can only wildly speculate about what could cause numrows or
sql_num_rows(mdb)'s return value to not reflect the fact that there is
in fact a result returned by the query.

I've compared my sources to the latest branch in the git repository, but
my coding skills are basic and nothing strikes me as being the obvious
fix I could just patch in to finish the job. I would be grateful if a
person more familiar with Bacula code could point me in a direction to
try and get db_find_next_volume to play nice.

Regards,

Lucas

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users