I have a script that opens up a store of .CSV tables and imports them all.
I created a cursor and built a statement on the fly in the loop like this:

 EXECUTE IMMEDIATE 'IMPORT TABLE ' + TableName + ' FROM "' + TableName +
'.csv" IN STORE "MyImports"';

But then I added parent-child constraints so the tables have to be imported
in a specific order, parent tables first followed by child tables.

So I thought I'd get a little smarter and instead of building the 'IMPORT
TABLE...' statements for each table, I'd PREPARE a STATEMENT with
parameters, then just call each statement with a USING, like this:

 PREPARE ImportStmt FROM 'IMPORT TABLE ? FROM "?.csv" IN STORE
"MyImports"';

 EXECUTE ImportStmt USING 'Table1';
 EXECUTE ImportStmt USING 'Table2';
 EXECUTE ImportStmt USING 'Table3';

Alas, I got an error on the PREPARE statement that a table name is expected
but ? was found.  I guess there are rules for where parameters can be placed
in a statement.  I expected to have a problem inside the quotes, but this is
referring to the first ? (I confirmed this by replacing the second one with
an actual filename).

Of course, I simply built each statement individually to get the script
working, but have run into this a few other times in the past.  I think I
was trying to specify the table name in a FROM clause and that didn't work
either.  In any case, is there a place in the documentation that describes
or infers where and how parameters can and cannot be used?  Or is this
something that really should be doable?

--
David Cornelius
Cornelius Concepts

David


As of this point in time you can't pass tables etc (I forget the proper name for them) as parameters. Tim has it down for an enhancement.


Roy Lambert [Team Elevate]

Roy,

<< As of this point in time you can't pass tables etc (I forget the proper
name for them) as parameters. Tim has it down for an enhancement. >>

Um, no I don't. There's no performance benefit to using parameters for
table names, so I won't be adding such a feature.

--
Tim Young
Elevate Software
www.elevatesoft.com

David,

<< So I thought I'd get a little smarter and instead of building the 'IMPORT
TABLE...' statements for each table, I'd PREPARE a STATEMENT with
parameters, then just call each statement with a USING, like this: >>

Keep doing it like you were doing before.  Using parameters for table names
is not supported - parameters can be used any place that a literal constant
could be used, and a table name is an identifier, not a constant.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

><< As of this point in time you can't pass tables etc (I forget the proper
>name for them) as parameters. Tim has it down for an enhancement. >>
>
>Um, no I don't. There's no performance benefit to using parameters for
>table names, so I won't be adding such a feature.

I thought you did. Is it just field names or none of them?

Roy Lambert

OK--thanks.

--
David Cornelius
Cornelius Concepts

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:C2F547B6-2CE3-4936-8BF3-1EC8F16408EE@news.elevatesoft.com...
> David,
>
> << So I thought I'd get a little smarter and instead of building the
> 'IMPORT TABLE...' statements for each table, I'd PREPARE a STATEMENT with
> parameters, then just call each statement with a USING, like this: >>
>
> Keep doing it like you were doing before.  Using parameters for table
> names is not supported - parameters can be used any place that a literal
> constant could be used, and a table name is an identifier, not a constant.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>

Roy,

<< I thought you did. Is it just field names or none of them? >>

You simply can't use identifiers with parameters, so the answer is "none of
them".

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

><< I thought you did. Is it just field names or none of them? >>
>
>You simply can't use identifiers with parameters, so the answer is "none of
>them".

Do you know where I can get a memory supplement

Roy Lambert