Is there a way that I can make FileOverwrite() write to the server rather than the client?
- OR -
Is there a way to make @Macro() read the file from the client rather than the server?

Either one of these would solve my problem. I am constructing a macro file on-the-fly and writing it to disk. It works perfect in standalone mode, but bombs in Server/Client mode, because the macro file is being written locally to the client, then @Macro is looking for it on the server.

I tried using a series of QuickMacro commands instead of a macro file, but there is one spot that QuickMacro hangs and causes me to kill Sesame with Task Manager, where @Macro does not have this problem.

Thanks for the reply, Bob.

I wanted to create universal code that wouldn't depend on any external settings or tweaks to the network. I usually like to make Sesame self-sufficient.

I ended up with a workable solution. The code will simply need to run locally on the server machine at least once, in order to dynamically create the macro for that particular application's filename. After that, the macro will be there for the @Macro command to use, even though it might be a client that is invoking it. (The macro is still created and written to disk on the client, but that won't hurt anything anyway.)

This is for a client who (against my suggestion) really wants to use a new copy of the database for every group of people. I have no idea what names for those databases that she might use, so I needed to figure out something that would build itself.

The code is for a simple "Backup this Application" button, which automatically makes a backup copy of the application with the original name, followed by " Backup". (Clever name, huh?) The one thing that I can't make SBasic do without a macro, is type the name of the backup file, and select Yes to overwrite the old one. I know that there is a new command in Sesame 2.x called BackupApplication(), but I really don't like the way it works. It keeps creating brand new copies of the application, instead of simply overwriting one copy. With a large application, you can quickly run up a lot of disk space usage.

They could always use File/Save As, or backup from the command tree, but if they have lots of applications (as they will with their chosen method), that can lead to mistakes as to which file gets overwritten. So, I like to make it idiot-proof, and put code in a command button that does it for them.