Setting DestinationDB in code

[Assaf]

Hi,

I have an action query that creates a table in external
DBs. I'd like to set the DestinationDB property of the
query in code to let the user select from a number of DBs.

I know this can be done using the property sheet of the
query but is there a way to do so in code? Access
doesn't like: MyQry.DestinationDB
= "c:\somedir\somedb.mdb" (or anything similar I tried.)

Any hidden wisdom?

Thanks.

- Assaf

 

[Dev Ashish]

I know this can be done using the property sheet of the
query but is there a way to do so in code?

You can do that by parsing the SQL. The destination db is controlled by the
'INTO' clause in SQL.

-- Dev

 

[.]

destination db is controlled by the 'INTO' clause in SQL.

My situation involves goes a step deeper into destination db.

My FE db is large, and update usually is to code only. Therefore
my code exports standard module, and destination db 'A" imports it.
"A" exists only for purpose of applying module to ultimate target db "B".

I cannot find syntax to refer, in A's code, to **module** in B.

 

[Dev Ashish]

My situation involves goes a step deeper into destination db.

My FE db is large, and update usually is to code only. Therefore
my code exports standard module, and destination db 'A" imports it.
"A" exists only for purpose of applying module to ultimate target db "B".

I cannot find syntax to refer, in A's code, to **module** in B.

I'm afraid too much context was truncated and I'm at a loss. But as a
guess, the only way I think you can refer to 2 module instances in 2 dbs is
through automation.

accApp1.Modules("somemodule")
and
accApp2.Modules("someModule")

-- Dev

 

[.]

guess, the only way I think you can refer to 2 module instances in 2 dbs

is through automation.

accApp1.Modules("somemodule")
and
accApp2.Modules("someModule")

-- Dev

You grabbed the point in question.
I will explore the suggested approach, then report back.

 

[.]

guess, the only way I think you can refer to 2 module instances in 2 dbs

You grabbed the point in question.
I will explore the suggested approach, then report back.

Reporting back:
What I find is that nothing can be done to module in **non-current** db.

If somebody finds to the contrary, he should tell us, because it would be
a shame if a rare piece of knowledge were to go to the grave with the
knower.