Hi Everyone, Thanks for all the links and replies. They all have provided valuable insight into various options.
I will endeavour to go away and play around with these things. Please accept that I am not being argumentative relating the options proposed (e.g. using PostgreSQL+PostGIS) it is just that changing to this model requires a complete rethink of my companies data storage model, project management, client interactions, etc. Not something that can be addressed lightly. Moving to an open source OS and software has already created problems for an industry lost in the past*. Moving too fast generally see one standing alone as a pariah rather than an innovator. * a good example is a recent move from a relational database model for storage of plant and animal records in the state to a flat file where taxonomic, biological, distributional data is repeated over and over for every record. Apparently the relational database model is too confusing for other biologists in the state. Cheers Simon Simon Cropper Principal Consultant Botanicus Australia Pty Ltd PO Box 160, Sunshine, VIC W: www.botanicusaustralia.com.au On 02/02/11 12:10, Paul McNett wrote: > On 2/1/11 4:46 PM, Simon Cropper wrote: >> Just starting to play with Dabo App Wizard. >> >> Does anyone know how to make this work on dbase or VFP files directly? > > Currently, there's no support for it. Best to convert dbase or VFP data to a > supported database such as SQLite. > > >> I know that files can be imported to SQLLite but some of these files are >> associated with spatial data in ESRI Shapefiles (that is, I can't change >> them). > > You can't convert the Shapefiles? > > >> Essentially Shapefiles store all their attribute data in Dbase III >> format. External packages can readily access these files IF they don't >> change the file structure, field names or change the code page. I can >> access these files via VFP, at a pinch, if I want to manipulate the data >> in a way the GIS package does not allow. > > There are some python libraries for reading (and writing to) dbase/xbase > files. We > could write a dabo adapter for this to access directly, or you could use the > python > lib to convert to an in-memory sql database to feed to a dabo bizobj. > > >> As an introductory trial I was looking at making a simple >> point-open-edit dbase file editor. Just a simple file browser/editor to >> replace VFP on Ubuntu. >> >> It seems the AppWizard (a) does not support xbase files, > > Right, Dabo currently does not support xbase files. > >> and (b) the >> resulting applications are hard wired. > > Not quite sure what you mean by hard-wired. The resulting application is a > bunch of > source files that you can modify and build on to suit your needs. The intent > of > AppWizard is to get you part of the way to building your app structure very > quickly, > not to leave you with your final set-in-stone application. > >> The dGrid control looks promising but I need a way of >> seeing/querying/editing the dbase files, so I am pushed back to the need >> for an OS independent driver/odbc. > > With dGrid you can see/edit a Dabo bizobj recordset. > > >> Johnf had indicated that several modules exist to allow python to access >> dbase files but I have not found any that allow editing (the only one he >> actually pointed to allowed importation into Postgre). > > You say above you don't need to edit them. > >> The functionality for this simple program would be... >> (1) File/Open option to select an existing dbase/VFP file >> (2) This data to be presented in a grid (dGrid looks OK). >> - the user should be able to browse through this dataset in a >> continuous manner rather than in screen-sized chunks. >> - ULTIMATELY if a dbase/VFP index exists, the user should be >> able to seek() for a particular indexed item and if a memo >> field exists the user should be able to see this in an >> edit field. >> (3) Data to be able to be directly edited in the grid. >> (4) To be code-page aware (should respect the file's CP). >> (5) Filter/Queries and Separate Editing Tabs as in the AppWizard is OK. >> >> Anyone got some code that does something similar. Any ideas how I should >> start with this type of project? As I asked yesterday is their any extra >> sample applications people are willing to share that illustrate the >> appropriate concepts to achieve this task. > > I'd seriously consider converting the dbase to sqlite, even if it is one-off > in-memory on the fly, if it doesn't add too much overhead. Otherwise, we > could look > at wrapping one of the python libs to access dbase files directly. > > Paul > > _______________________________________________ > Post Messages to: Dabo-users@leafe.com > Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users > Searchable Archives: http://leafe.com/archives/search/dabo-users > This message: http://leafe.com/archives/byMID/4d48aef9.8080...@ulmcnett.com > > _______________________________________________ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/4d48c591.1030...@botanicusaustralia.com.au
