Unfortunately, it returns DB_OK. There seems to be some caching going on which I don't quite understand at the moment. Starting and stopping the db driver in the right sequence seems to be important. Anyway, I solved the problem by doing the deletion at an earlier point in the program.
Everything seems to work OK now. I'll do some tests with more complex tables, then post a patch. Benjamin Moritz Lennert wrote: > On 10/01/08 13:52, Benjamin Ducke wrote: >> OK, I have it almost working except for one annoyance: >> >> If the table already exists, then --o should allow the user to >> overwrite it. Thus, I check for that flag and delete the old >> table, if it exists, using: >> >> db_delete_table ( connection.driverName, connection.databaseName, >> new->answer ); >> >> But even so, the next call to >> >> db_execute_immediate() >> >> complains about the table still being there and creation of the >> new table fails. >> I suppose that db_delete_table() does not delete the table immediately? > > db_delete_table() sends a "drop table XYZ" sql query to the database > backend, so it should delete the table. > > Launching > > echo "drop table ggg" | db.execute > followed by > echo "create table ggg (cat int, value double)" | db.execute > > works without a problem. > > What does db_delete_table return ? > > Moritz > > _______________________________________________ > grass-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-dev > > -- Benjamin Ducke, M.A. Archäoinformatik (Archaeoinformation Science) Institut für Ur- und Frühgeschichte (Inst. of Prehistoric and Historic Archaeology) Christian-Albrechts-Universität zu Kiel Johanna-Mestorf-Straße 2-6 D 24098 Kiel Germany Tel.: ++49 (0)431 880-3378 / -3379 Fax : ++49 (0)431 880-7300 www.uni-kiel.de/ufg _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
