Uwe Grauer wrote:
So in my opinion you should only spit out the scripts to help making DDL easy. Do not do this from the application level.
In general, I heartily agree with this. I've not been overly concerned with getting this stuff as part of Dabo, because Dabo is the framework for the application, and the application should (IMO) assume that the data structures are already defined on the backend.
However, there is a powerful use-case for it: our desire to embed SQLite as a "local cursor engine" in Dabo. IOW, having user code creating mostly temporary, in-memory tables, indexing them, and then perhaps using these as datasets to feed to bizobjs and ui controls.
Another use case is the type of application where it is usually single-user and that some end-user will download and install herself, and a wizard will help her create the database. The user won't be thinking in terms of "database" but rather "data file". Where she can "open" a different database by using File|Open. Think about Quicken, ACT!, and other off-the-shelf applications. I also see this using SQLite.
So for enterprise-level apps where there will be a DBA, you want to provide a script for whatever database they are running (Oracle, Firebird, etc.) that the DBA will review, test, complain about, modify if necessary, and apply. But more likely, the data already exists on the backend and the Dabo app won't need to change it.
So I guess I see tremendous value in wrapping the DDL stuff, but only really with SQLite. IOW, exactly what we've been working on first! ;)
-- Paul _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
