On Saturday 04 August 2001 03:23, Jim Conner wrote:
> There is an Orders tarball(on SourceForge site) that is a sample database.
> In this tarball, take a look at Orders.kdb.  This file tells Rekall where
> and what to open for that database.  I haven't messed with Rekall much to
> get to know it very well.

It seems others are into this as well, so to that end I am posting an 
unverified 'howto' that I snagged from somewhere. Ymmv

No doubt, this group will ultimately come up with a refined SxS but here's a 
start.


-- 
http://linux.nf -- [EMAIL PROTECTED]
Get: 1. the rekall tarball 
 2. xbase-1.8.1 red hat 7.1 i.386.rpm 
 3. xbase-devel-1.8.1 red hat 7.1 i386.rpm 
 4. xbsql-0.3 tarball 
from the rekall files on sourceforge 

Get kdeb-0.1 tarball from 
http://prdownloads.sourceforge.net/rekall/kdedb-0.1.tar.gz 

use rpm -i to install xbase and xbase-devel in that 
order 

mkdir /usr/local/include (This is to accomodate the 
xbsql.h file 
that is copied---not installed---into this directory. 
The file is not in the rpm file available in the rekall 
files) 

unpack the xbsql tarball and do the standard configure, 
make, make install. 

unpack and configure kdedb 

delete "informix" from SUBDIRS in the Makefile in 
kdedb/plugins in the unpacked directory. This is 
because red hat 7.1 out of the box comes with mysql and 
postgress but not informix. 

run make and make install in kdedb 

mkdir /usr/include/kdb 

copy kdeb/kdb/*.h from the kdedb unpacked files into 
/usr/include/kdb 
This is so the make of rekall will go. 

unpack rekall and do the standard configure, make and 
make install 

I was unable to get any other sequence of commands to 
work with the files available. There were numerous 
discrepancies in locations and libraries that would not 
work with the rpm files for xbsql and rekall. I don't 
know if there is an rpm for kdedb 



Once the install goes, there is then the problem of 
figuring out how to run the beast. There is a LOT of 
functionality missing. Not all the datatypes of 
standard sql are available. In particular, there is 
only one kind of primary key available. There are tons 
of messages that are pumped to controlling terminal as 
the program runs. If I have time I will start to list 
them, but there are too many to really deal with now. 

One glitch in functionality is that the reload button 
on the table screen does not recognize when another 
connection has changed a table. If I use kmysql to 
change a table, then the change is not reflected in the 
rekall table screen even if the reload button is hit. 
If the table screen is killed and a new screen is 
opened, then the change is seen. 

Reply via email to