> Yes, that's what I suspected. Because your table_a has no natural key, you > have > no good way to select the auto-generated id value. You can find out what the > last > auto-generated value was, which lets you work a row at a time, but you're > really > suffering from a poor design choice. > > If you make val unique -- and I see no reason not to -- then you can select > the id for > every val you insert with "where val = 'value' ".
Hi James, Thanks for the follow up. I am certainly open to critique and although this is working I would rather have it right. I realize I omitted the fact that val in table_a is unique. Given the unanimous opinion within the thread I bit the bullet and just refactored but I am still keen to leverage one large self-contained sql script. The reason is, accessing pure dbapi c code in python is fast but the module I am now using still mixes in plenty python in there and it's not nearly as fast as the proper programmatic approach to inserting and using code to deduce the rowid, followed up with the related inserts while using mostly python dbapi. Sending one large statement in this case would bypass the overhead, but using val as the reference would make the string very long. That text data might be several thousand chars long. As soon as I have a moment to revisit this, I will try Simon's suggestion. Thanks, jlc _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
