<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hello Jim, hello David,<br>
<br>
I have had this problem and found 2 solutions<br>
<br>
1. somewhere there is a read-only interface to .DBF's (vaults of
parnassus I think). I think minor tweaking would make it read-write.
indexes are not supported, but it's about 150 lines, so, basic, basic !<br>
<br>
2. installing visual foxpro with the odbc drivers lets you use mxODBC
(and the native python odbc). The Vfox Odbc driver does understand
compound index files (.CDX) and uses them properly to access records by
index (i.e. c.execute("select * where id = ?id", ('xx',)) uses the cdx
index if possible, not a table scan).<br>
<br>
I can't remember for sure if CDX indexes appeared after clipper 5.2,
but I think they were there already.<br>
<br>
This allows you to use the original dbf format (which excel also can
read, the one with no nulls, signature 0x03 in the header), and also
the newer vfox format (which allows nulls, but neither excel nor
clipper can read nor write, and has signature 0x83 in the first byte).<br>
<br>
I have found that I could write code that could read and write either a
DBF or the same table on db2/oracle/postgres, pretty much with no
change of code, just by opening a different ODBC dsn; that has helped
me transition some DBF-dependent code to python and then to sql
servers. Of course you have to go for the lower common standard of sql
if you want interoperability.<br>
<br>
I've written a table module that allows tables to be treated like a
mutable list of objects (and across vfox/db2/oracle/dbf), but it's not
pretty (one of my first coding attemps):<br>
t = table(dsn, "select * from blah", pk=(id,id2,id3,etc))<br>
for r in t:<br>
print r.id, r.name<br>
r.name = r.name.upper()<br>
<br>
will print and uppercase the name column in the table, committing at
the del of r.<br>
<br>
Please get in touch if you'd like to discuss.<br>
<br>
-frederic vander elst<br>
<br>
jim wrote:
<blockquote cite="mid200503150208.17372.jlh@yvn.com" type="cite">
<pre wrap="">David:
Thanks for the reply.
</pre>
<blockquote type="cite">
<pre wrap="">--- jim <a class="moz-txt-link-rfc2396E" href="mailto:jlh@yvn.com"><jlh@yvn.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I have bindings for the xbase-2.0.0 c++ library with the sip files
and a python wrapper module.
I would be willing to share if there is any interest.
</pre>
</blockquote>
<pre wrap="">I suggest that you either:
a) (preferably) establish a SourceForge project
</pre>
</blockquote>
<pre wrap=""><!---->
I'll look into sourceforge. Other than creating a project there, do you have
any suggestions about how to publicise this in an approved and useful
fashion? Not to gain fame and glory, but to let others who need it, find it.
</pre>
<blockquote type="cite">
<pre wrap="">Based on personal experience, I advise you not to get too hung up
initially on issues such as whether the module builds out of the box on
36 platforms and whether it covers every last corner of the underlying
C++ library. Those issues can be ironed out in due time.
</pre>
</blockquote>
<pre wrap=""><!---->
My plan exactly. I am building it for my own use at work. So, things that
annoy me will get dealt with. Those that don't will wait till someone whines
about it.
At the moment, I can build it on linux-gentoo and win2k borland 5.5. Again,
until someone else whines about it, I won't bother with anything else.
</pre>
<blockquote type="cite">
<pre wrap="">With regard to early documentation, it'd be helpful to explain how the
module compares to other python-xbase modules and what your ultimate
goals are.
</pre>
</blockquote>
<pre wrap=""><!---->
My goal is to have a way to seamlessly work with the Clipper5.2 production
data software/system at work with python. All data are currently in clipper
xbase dbf files.
Clipper was as good as it got in '95 when I started work there, and still is
better than most, but has been abandoned by Computer Associates and starts to
not work in a serious fashion when you get to Win2K. Works Ok with 98 but is
still a dos program at heart.
However, I have ~500k lines of code that work and work pretty well and don't
want to even think about an abrupt switchover -- thence a gradual transition
to python, from there eventually to some sort of SQL database instead of
xbase.
So far as I can find, there are *NO* other xbase-python modules.
mxOdbc/windows ODBC sort of works with clipper dbf files if you don't want
indexes. Other than that, I don't know of anything, and I have looked pretty
hard.
Now, I suppose that you will tell me about some project that does everything I
need if I had just found it ( Hope, Hope, Hope?) but not expect.
For the moment, documentation is implicit in a python unittest module that I
have been using to debug. This will grow as I find bugs and need tests to
excorcise them. That and a README that this email is the start of.
</pre>
<blockquote type="cite">
<pre wrap="">This'll help programmers who are browsing for a "Python
xbase module" to decide whether yours is worth investing time in.
</pre>
</blockquote>
<pre wrap=""><!---->
Any further suggestions regarding the above thoughts would be most welcome.
Jim
_______________________________________________
DB-SIG maillist - <a class="moz-txt-link-abbreviated" href="mailto:DB-SIG@python.org">DB-SIG@python.org</a>
<a class="moz-txt-link-freetext" href="http://mail.python.org/mailman/listinfo/db-sig">http://mail.python.org/mailman/listinfo/db-sig</a>
</pre>
</blockquote>
</body>
</html>