>No, I don't think you are being "thick" on this one. Your point and approach is well taken. There are many times that "we" as developers tackle things almost with a "one track mind" and later on we find a "six million dollar man" solution. If I had to redo it again, I would certainly try something along the lines of your approach, but for now, the client will not be pleased with an additional re-engineering bill.
>
>Regardless of approach, what is really wrong here? Is it a macro substitution deficiency or an OS problem. According to Ken Weber on this thread, the sample code that I provided works well under Win95. I however, am using NT 4.0 and it fails miserably.
>
>I happen to feel that it is a macro substitution deficiency or anomally because the same file name can be used in a USE statement with no problem.
>
>ie.
>m.lcPath = "c:\December 1998\test.dbf" && Note, no quotes
>USE ( m.lcPath )
>

I've read the solution to your problem by other folks, I'd just like to add one thing here: you now have an open table; you may want to assign it an alias and mention that alias in the SQL later.

Couple of reasons for this:
- I'm not sure what would happen if you mentioned "from test" and your app's directory contained test.dbf;
- if you're using just an alias in the SQL, you run less of a risk that your macro may get too long. You actually have no macro this way;
- the SQL becomes more generic - you may just stuff this into a routine where the path is supplied as a parameter, so you don't have anything to build at runtime, just the m.lcpath from the pcPathParameter and "test.dbf". No macros.
- the SQL becomes shorter, and you have less chance that it may be too long to compile.