views:

56

answers:

3

Ok this is vexing me. I have a query I created with an in statement in the from clause. What I am looking to do is have a global variable populate that from statement. Example

Select *
Form query1 in <Global Variable filename>

What is going on is I link to a file that has hundreds of linked table and queries in it. My database only has a few select queries and link table to different database. I did not want to re-build all the queries and linked table is my database. The issue is the file with all the links changes name once a month. I just want to read a text file with the current name of the database in it so I do not have to keep changing my queries every time the database name changes. Also this has to a query since I have other queries using the externally linked query.

+1  A: 

I have one suggestion, but its pretty kludgy.

Rewrite the query on the fly with VBA call

Private Sub update_qtest()
Dim db As Database
Dim qd As QueryDef
    Set db = CurrentDb
    Set qd = db.QueryDefs("qtest")
    qd.SQL = "SELECT * from query1 in " & g_file_name
End Sub

As I said, it's kludgy, but I don't think there's a way to pass the from clause as a parameter.

CodeSlave
I agree. char char
Remou
Why is it kludgy? The FROM clause of a Jet/ACE SQL statement is not paramterizable. That's just the way it is, so writing the FROM clause on the fly is the only solution.
David-W-Fenton
I find it kludgy because it's counter intuitive to an outside developer. In my world, it's rare that I would have to do something like this. When I see a query object (or a recordsource in a form/report), I expect that it is a a static entity. Updating on the fly like this will mean that some later developer may come in to change/enhance the application; make a change to the Query, expect it to stick, and then have it reverted somewhere else in the code. I'm currently dealing with an app where the last guy did a lot of this because he didn't know how to use parameters, and it's a real pain.
CodeSlave
Don't get me wrong, code that can re-write it self is cool and can be useful. But it can make things more complicated than they need to. Besides, by the definition [A kludge is a workaround, a quick-and-dirty solution, a clumsy or inelegant, yet effective, solution to a problem, typically using parts that are cobbled together.] I humbly would say that piece of code meets the criteria.
CodeSlave
I agree that rewriting saved QueryDefs can be problematic, and it's a practice I completely avoid except for cases where it is essential (such as a graph of TOP N where the users chooses the N at runtime -- no way to do it without a saved QueryDef that is rewritten at runtime). I generally avoid saved QueryDefs in general, in fact. Does you object vanish if the dynamically-written SQL is used at runtime but not persisted in a saved QueryDef?
David-W-Fenton
A: 

So you have a query like this:

SELECT *
FROM query1 IN 'C:\somewhere\AnotherDb01.mdb';

Next month, you want to substitute AnotherDb02.mdb for AnotherDb01.mdb

However, the database engine will not let you do that substitution at the time you run the query. There is no way around that.

Think I would pull query1 into your working database. Create links to any of the tables in the external database it needs. Then each month, use the linked table manager to identify which external database the links point to.

HansUp
A: 

Another way to do this would be to just use the same file name each month so you wouldn't have to change anything in your Access app at all. You could easily code copying the file to the standard name over top of the previous copy (you'd have to delete it before copying, of course), which would retain the history.

David-W-Fenton
I can see some problems with this if there is no immediately obvious difference when the file is opened. If there is any disorganization, the file may not be copied and no one will notice because the name is the same.
Remou
Well, of course, you'd program the process and make backups and such. Right?
David-W-Fenton
That is quite a chunk of coding for something that happens once a month, especially when you would have to check that nothing had changed during the month.
Remou
Well, it's a way to avoid having to change a saved QueryDef. On the other hand, you might very well want to have an organized way of handling which files had been processed and so forth, so it's not inconceivable that you'd be doing most of that coding already. For me, I'd just use linked tables and change the connect string as needed. Depending on what I'm doing with the data, I might use dynamic SQL in a form or report's RecordSource, but I don't do that all that often (though I just implemented it in an app yesterday).
David-W-Fenton