Hi , As you said :
"If you look at content.xml file, it contains table/column definitions. The database/script file you're mentioning contains HSQLDB or other backend-specific SQL (yes, there's no respected standard). I am guessing the xml is easier to parse than the specific SQL. " I tried to parse content.xml but the problem which I faced is that content.xml does not contain every information.For e.g the samples downloaded from source provided by you ( http://www.floppybunny.org/robin/web/virtualclassroom/chap8/libreoffice_base.html ) had a file under name "cons2.odb" in which by simply analyzing (after unziping .odb file) content.xml file , we don't gets necessary information regarding- Primary key and other constraints, and also for some tables it doesn't states any column at all which are originally present there in database.And regarding tuples (i.e instances or values or data) its present in "file_name/database/data" file but under some encoded scheme (till now I couldn't found out the scheme,as I haven't thought of it much).So considering above issues I think I will have to parse script file only (though a little more information can be gathered from setting.xml but that will not sufficient) . If possible , I would like to have your views about my approach and suggestions towards it. Regards Jayesh Hathila On Thu, Feb 20, 2014 at 6:02 AM, Jaroslaw Staniek <stan...@kde.org> wrote: > On 19 February 2014 22:21, Jayesh Hathila <sharma.jayes...@gmail.com> > wrote: > > Hi, > > ( In addition to my previous mail ) > > I am attaching perl script which unzips the .odb format.The script will > > create a folder with the same name as .odb file except extension (e.g > > file.odb converts to file folder).After unzipping till now I have been > able > > to get the query about tables in file named script in > > /file/database/script path which can be directly used in kexi.Please > have a > > look at the code and if possible reply any error you found in the > approach . > > > This is a good and needed step in analyzing the odb format. > > In ODF filters development I've been using such an 'unxml' script: > > ------8x----------- > #!/bin/bash > unzip -o "$1" || exit 1 > for f in `find . -name \*.xml* -o -name .rels | grep -v -e "\.svn$" -e > "\.svn/"` ; do > xmllint --format "$f" --output "$f" > done > ------8x----------- > > In addition to uncompressing it reformats the xml files to make them > human-readable. > > In the actual code > > PS: Sample .odb databases are available eg at > > http://www.floppybunny.org/robin/web/virtualclassroom/chap8/libreoffice_base.html > . > > If you look at content.xml file, it contains table/column definitions. > The database/script file you're mentioning contains HSQLDB or other > backend-specific SQL (yes, there's no respected standard). I am > guessing the xml is easier to parse than the specific SQL. > > PS2: In the actual C++ implementation, KoOdfReadStore class from > calligra libs can be used to read contents of the .odb. > > > > > -- > regards / pozdrawiam, Jaroslaw Staniek > Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org > Qt for Tizen | http://qt-project.org/wiki/Tizen > Qt Certified Specialist | http://www.linkedin.com/in/jstaniek > _______________________________________________ > calligra-devel mailing list > calligra-devel@kde.org > https://mail.kde.org/mailman/listinfo/calligra-devel >
_______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
