As I understand the workings, the files under the model directory define the tables and relations and the connection string to the database server. Without that DAL is a bunch of code with nothing to play against to tell it what to do with the database for the data access.
The databases directory contains files that assist with the migration of the database as the model changes through code editing. So for example if you were to drop the database, create an empty database using psql for Postgres or mysql for MySQL at the command line, remove the files from the databases directory and start the web2py instance and hit the application home page then all the tables, fields and relations will be created by the migration process in the empty database. So that would be a way to start with a new empty database and have the application fill it from there. If you have some base data you want to load in there is a way to export all tables to CVS file and import all data back to database - check the manual DAL chapter. If you are using SQLite then the database file is also under the application/myapp/databases directory. If you use a server oriented database you typically have no meaningful access to the files the database server uses to implement the database. I think I understand what you want to do. If you are using SQLite then the database is in a file so I would move the databases directory to the unique build number directory which would preserve the data and the migration files. I have never tried this but in the location you run the DAL from I presume you have the original location of the databases directory. If you were to make a databases symbolic link to the build directory end point databases directory you want to run with at this moment in time then the program might run with that linked in directory. If you are using a server based database then you are probably better off exporting the tables of interest as a csv to the build unique directory and if you want to review that data then load the data back into an empty table. How hard this is to get working depends on how complicated the database schema is and whether or not foreign keys are involved. Also if it could be the entire database then the DAL export call to export all tables at once works very well in my experience with restoring foreign keys etc. when the import is used. Hope that helps Ron
