@Likit, > ProgrammingError: (1146, u"Table 'jodb.joke_category' doesn't exist")
It looks as though you have '.' (period) in the table name and that is probably causing the problem. If that is not the case, could you show us your db.py file? We could really help then. On Jan 12, 12:03 am, Likit <[email protected]> wrote: > I mean, why won't web2py create the tables through its famous DAL. > > I have created the database directly in mysql. > > On Jan 11, 8:44 pm, Likit <[email protected]> wrote: > > > > > > > > > I guess I like SQL better than frameworks. SQL is a query language for > > DDL and DML that is well documented and completely explicitly. > > Frameworks are opaque and invent a new syntax subject to ambiguities > > of parens, square braces, curly braces, dotted names, sometimes > > tablenames being implicit, sometimes fieldnames being implicit. Why? > > > So, I have repeatedly tried to make a link table like the famous dogs > > and owners tables in the Web2py book to no avail. > > > Each time there is a problem I must do the following: > > - drop the database from mysql > > - stop apache > > - stop mysql > > - delete the web2py application via the filesystem > > - restore the web2py application via the filesystem making sure that > > the cache and session files have been deleted > > - restart apache > > - restart mysql > > - create the empty database in mysql > > - run the web2py application > > > But, web2py's DAL fails to create the tables. Because the errors > > appear to be in the framework itself, the diagnostics are completely > > opaque through several layers of calls. The ultimate error is that one > > of the tables is not being created. But, that is circular--that is > > because the DAL failed to create the table for a brand new web2py > > application in an empty database. > > > Judging from the references below it is because of a faulty > > migration. it's not like the most trivial migrations EVER work. it > > appears that some detritus of the previous application or tables > > exists so that web2py attempts its failed magic by doing a migration. > > > So, perhaps the real question is how does one purge every possible > > vestige of both the tables and application so that web2py does not try > > any of its so-called magic (which is supposed to be very unpythonic, > > in any case). > > > I've wasted nearly 60 hours on web2py and am about to stop wasting any > > more time. There seem to be many reasons that php, jquery, and RonR > > have dusted python for web development. > > > Here is the traceback: > > > TRACEBACK > > > Traceback (most recent call last): > > File "C:\web2py\gluon\restricted.py", line 204, in restricted > > exec ccode in environment > > File "C:/web2py/applications/pyjokes/models/db.py", line 55, in > > <module> > > Field('category_id', 'integer')) > > File "C:\web2py\gluon\dal.py", line 5097, in define_table > > polymodel=polymodel) > > File "C:\web2py\gluon\dal.py", line 728, in create_table > > fake_migrate=fake_migrate) > > File "C:\web2py\gluon\dal.py", line 816, in migrate_table > > self.execute(sub_query) > > File "C:\web2py\gluon\dal.py", line 1359, in execute > > return self.log_execute(*a, **b) > > File "C:\web2py\gluon\dal.py", line 1353, in log_execute > > ret = self.cursor.execute(*a, **b) > > File "C:\web2py\gluon\contrib\pymysql\cursors.py", line 108, in > > execute > > self.errorhandler(self, exc, value) > > File "C:\web2py\gluon\contrib\pymysql\connections.py", line 184, in > > defaulterrorhandler > > raise errorclass, errorvalue > > ProgrammingError: (1146, u"Table 'jodb.joke_category' doesn't exist")
