Hi Paul, Muy comments are inserted in the dialog
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. Not a suitable solution for most files. Every job has multiple files. I would need to globally import and export them. Even though the state government agencies now store in Oracle SDE, they release and expect data back in shapefiles that use dbase III files. > > >> 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? Reference sets can be readily imported into a central database but as stated above every job requires using and giving back to the client/government shapefiles. I could globally import and export when receiving data but this adds to the workflow for every project. > > >> 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. > OK > >> 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. What I mean as hard-wired is that you select a database and the AppWizard creates the forms to access this data. My 'beginners' app selects the file dynamically (that is the file strucure is not know until runtime) and the grid would need to be 'setup' on the fly based on information gleaned from the header. > >> 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. Query: If your grid is 10 rows deep, and your bixobj recordset is 100 rows. Does the grid allow you to scroll through the rows with the mouse wheel or up/down arrows? > > >> 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. > That is OK when you just want to query, but unless you can reverse the process and write the memory data back to disk, so it can be given to a client/government agency, this solution will not work. Plus I am not sure how using such a technique would impact on the shapefile integrity if the order of data is changed (e.g. record 1 is now record 10). Cheers Simon Simon Cropper Principal Consultant Botanicus Australia Pty Ltd PO Box 160, Sunshine, VIC W: www.botanicusaustralia.com.au _______________________________________________ Post Messages to: [email protected] 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/[email protected]
