<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>The whole data to report question is a huge part of Koha. The web interfaced based scripts are essential that give the info desired for end users without their having to worry about code. But isn’t that the question? Getting non-coders the tools to get the particular data set desired.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>My way around the report limitations of any canonical software (Koha included) is to connect the MySQL data to a ODBC application, either OpenOffice/BibLibre Writer document through Base with merge data (excellent for printing customized patron cards or labels) or to Word and Access. Once I set up the database queries through Base or Access, the librarians only have to click on the report they want and a dialogue box opens to filter by date or patron number or any other category that is essential to the data. The appearance of the reports is very polished because of the text editing tools available to a merge template in a document editor or a database frontend like access’s reporting tools. Granted, this is mean for printouts and not for the online interface, but the librarians still like to have printed reports for many day to day operations. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I did try out phpMyAdmin for a while, but generally use Access with ODBC drivers to work with the data directly. Sometimes I use Webmin’s MySQL module to view the data and run the queries. Of course the most efficient way is command line SQL syntax, but front end helpers really make editing the queries easier.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I know it is preferred to keep everything “in application,” but this is what my brainstorm has come up with.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Marion<o:p></o:p></p></div></body></html>