Brio report tool is on server \\gemini and has c: d: e: drives on the local system. The NT System %temp% variable setting is on d:\wintemp. d:\wintemp exists and is used by the rest of the software on the server just fine.

A shared VFP .dbc is on server \\gershwin\timetrak\datarep. The tables that belong to the .dbc are in \\gershwin\timetrak\data.

Configuring Brio on \\gemini, I setup an ODBC connection to a system-level DSN which points to \\gershwin\timetrak\datarep\genrep.dbc.

Brio, via SQL, creates tables in your database to hold Brio-related information (connections, licensing, etc). It does this whether you are using VFP or MSSQL or Oracle and probably everything else.

When the ODBC driver creates tables for Brio, it looks like it creates .tmp files in the \\gershwin\timetrak\datarep directory, and then looks to rename them to .dbf - but it looks in the local d:\wintemp directory instead of the place where it created them. I think this is definitely a VFP ODBC driver bug.

My workaround was to

1. Map m: drive on \\gemini to \\gershwin\timetrak
2. Point the \\gemini %temp% logged-on-user variable to m:\datarep
3. Let Brio create the tables
4. Stop the Brio service on \\gemini
5. Start up VFP6/SP4 on my desktop PC and open up the .dbc
6. In the DBC designer, I double-clicked each table and
when VFP said it couldn't find the .dbf, I pointed it to
\\gershwin\timetrak\tablename.dbf
7. Closed my VFP develo environment
8. Started the Brio service

Now it all works.

Maybe I should log this with Microsoft? Who do I email?