Re: [DB-SIG] xdb-xbase bindings for python

[Frederic Vander Elst]

Hello Jim, hello David, I have had this problem and found 2 solutions 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 ! 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). I can't remember for sure if CDX indexes appeared after clipper 5.2, but I think they were there already. 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). 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. 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): t = table(dsn, "select * from blah", pk=(id,id2,id3,etc)) for r in t:     print r.id, r.name     r.name = r.name.upper() will print and uppercase the name column in the table, committing at the del of r. Please get in touch if you'd like to discuss. -frederic vander elst jim wrote: David: Thanks for the reply. --- jim <[EMAIL PROTECTED]> wrote: 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. I suggest that you either: a) (preferably) establish a SourceForge project 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. 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. 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. 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. 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. This'll help programmers who are browsing for a "Python xbase module" to decide whether yours is worth investing time in. Any further suggestions regarding the above thoughts would be most welcome. Jim _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig

_______________________________________________
DB-SIG maillist  -  DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig