thanks ron_m :), yes that about the size of it :) I tried that, but I didn't know that part about the migrate where the models are changing (or the same)... Maybe that may explain my poor success here... So, you're saying the the "client" has to have a copy of the model? I don't get that... Is there a way around that? Is there a way around that? I wonder, would it be possible to fake it? I.e. have the same model but no data?
Here's then is the issue (maybe you have a good suggestion? :) ) I use DAL (no web) to manage the build data. Every build starts with nothing. on build_start(), things get generated, build happens, then everything gets deleted from the file system. Here's what I would like to do better: Before any traces of the build gets deleted, the build output, artifacts and the entire DB gets delivered to the storage server. all builds get delivered to a unique end location (the build's parent folder is named with the build's version number - so its unique), but the structure for the tail end of the path is identical - so everything says pretty much predictable. I would 1) like enable connections to these individual DB and 2) I would like to centralize the build data I keep under a central web2py instance and central DB, but I don't want to merge that data, i would like to keep it separate (at least in separate tables). Can we add entire tables (including its data) to an existing DB) and change the table names? Or even better, can we have the tables live in a different directory the the db file? (i have doubts, but thought it worth asking) Sorry for the convoluted 2nd paragraphe :( - I find English hard to write and I'm always thinking I am not being clear, so I write more (like this sentence ;) ) Anyways, thanks for the reply and I welcome any ideas or suggestions. Mart :) On Jan 13, 8:08 pm, ron_m <ron.mco...@gmail.com> wrote: > I think I understand you want to run Python programs with the DAL embedded > standalone as well as multiple instances of web2py. > > You should be able to do that, the database will treat each client as a > different connection. The migrate option on the table definitions should be > true only on one copy where the model is changing or on no copies of the DAL > if the model is static.
