That's what I thought and that's what I had but the tables were still sticking around... I figured, it was probably just a way to keep some record of activity around... so, thanks for that, I will re- insert those lines and see about my refresh issue.
Thanks a bunch, and much appreciate the reply, Mart :) On Oct 18, 10:59 am, ron_m <ron.mco...@gmail.com> wrote: > http://web2py.com/book/default/chapter/06?search=drop#drop > > db.table_name.drop() > > Ron > > On Oct 18, 7:40 am, mart <msenecal...@gmail.com> wrote: > > > Hi, > > > does anybody know how to delete a table using dal.py? I need to > > provide users with the choice of starting a process from scratch (and > > over and over again until satisfied). Which means on the first go, a > > user who is defining some steps in a software build setup, may be > > configuring, let' call call it step_E, which cause a table to be > > created @ runtime. Then as the user is continuing to setup and tweak > > his build setup, he may decide that step_F is better suited. Since > > these tables are created on the fly and that step_E is being replaced > > with step_F, the step_E table needs to disappear. So, is their a way > > to not just drop the records, but he entire table it self? if not when > > all tables get delivered as part of the overall build reports, then > > the testers will look at the contents and see an empty container (the > > step_E table)... from experience, this type of confusion never, ever, > > goes away. so to have a method to look at the set of generated tables, > > and remove those not listed is the best remedy. > > > And, if I tell them to blow away the entire staging area and start > > over, there will be some panic ;) So, we keep the good tables where we > > don't update/insert if nothing new and delete the bad tables... Can > > anyone help? > > > Again,any help is appreciated, > > > Thanks, > > Mart :) > >
