comment on

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?

In reply to Re: DBI and SQLite's .read feature by Marshall
in thread DBI and SQLite's .read feature by aplonis

Are you posting in the right place? Check out Where do I post X? to know for sure.
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
Want more info? How to link or How to display code and escape characters are good places to start.


The stupid question is the question not asked
	PerlMonks