Re: DBI and SQLite's .read feature

[Marshall]

You wrote:

So in SQLite you can do a .read to run all the SQL commands inside of a *.sql file. So in effect, you can drop and build temporary tables, populate them and finish with a SELECT at the end.

From the SQLite command line tool:
sqlite> .read create.sql

In Perl, it is completely possible to issue this: '.read create.sql' command to the SQLite tool.

I don't know where this 'create.sql' file comes from and I don't know where this "final SQL SELECT" statement comes from?

I would run the .sql file (either manually or via Perl). Then use Perl to scan that .sql file for CREATE TABLE statements, extract the table names and then run via DBI SELECT * from TABLE x statements. What am I missing here?

[Corion]

You don't even need to scan the incoming SQL file for CREATE TABLE statements. The DBI $dbh->table_info( method will give you all tables in a database, and for an SQLite database, most of these tables will inevitably belong to one of the SQL files.

[Marshall]

Your post is completely correct.

I am not sure what the OP's "real problem" is. A better explanation of the "work flow" would help a lot.