Opening files from wrong location

[AndriesV]

Running FM6 on Windows against FMServer 5.5.

Hope this is the correct forum to post this question. Even though at first glance this may appear to be an ODBC question, it's just mentioned to explain the setup.

In attempt to reduce the ODBC reporting burden for the FMserver users we created a separate storage location where the last-night backup from our production files is being copied to.

The problem is this: The few users who have access to the reporting backup files open this data-set every now and then to run some reports through ODBC connections, so far so good. After they close these files and connect to the FMServer production databases, the client opens relationships to some of the offline reporting files even though the normal production files are already opened from the server. Only renaming the backup set folder name or removing a drive-mapping to this location will avoid having open files from both the server and the offline set at the same time which of course is very undesirable.

I have already made sure that no script is storing the full path to this location. Somehow the FM client remembers this recent file location.

Does anyone have any suggestions? Is there some option or registry key to turn of this behavior?

Thanks in advance,

Andries

[LiveOak]

I'm not sure this is 100%, but you might try deselecting the "Save Relative Path" option in dialogs selecting files. Hopefully this will force FM to only look at the original files.

-bd

[Anatoli]

RE: path -- It often doesn't work.

From my experience I've found, that best is to rename databases with developer *only*! Not from OS.

[Peter2543]

It is known that FM opens files from the wrong location.

What also happens, that shortly after closing a file, and opening another file, it will open the first file too. Via relations to other files at the wrong location (relations, portals, scripts) more other wrong files can be opened.

Unfortunately, no sure strategies against this are known.

I use relative adressing and change folder names to break that behaviour.

[CobaltSky]

Unfortunately, no sure strategies against this are known.

I use relative adressing and change folder names to break that behaviour.

There are some sure strategies against this:

1. Never have more than one file with the same name anywhere on your system

2. Compress or encrypt all but the current 'active' copy of a given file.

However simply renaming the folder in which a copy of a file resides, while it helps, is not a water-tight solution.

[Anatoli]

Ray is absolutely correct.

Since I am doing those 1 -- 2 I've never had single problem.

[Peter2543]

They are right, this is a known, but hard solution.

But why does Filemaker remember the last file opened, sometimes? Why is changing folder names, on Windows, not sufficient? Are sockets or buffers hanging around?

I agree that on MacOS, name changing does not help, since the folder ID, and file ID, are independent of their names - it is easy to remember a file programmatically and open it with PBcalls no matter what its current location and name are.

What hurts too is that seemingly portals store the file reference from the relation, not only the relation. Even when the relation has been updated, accessing a layout screams for the file. As seen by me, perhaps I'm wrong.

Peter

[Peter2543]

It is legitimate to use an offline database, what the first person asked for. Encrypting files does not help for this application. What should he do?

Peter

[CobaltSky]

Well, he could have users open the files from an opener file which uses the Troi File, DialogMagic or File Tools (or one of the various other equivalent plug-ins) to dynamically rename and move the alternate (local) versions of all the files prior to accessing the hosted copies.

The opener would then have to be configured to automatically restore their names subsequently when desired.

On the face of it it may not be ideal, but it would be a better option than the risks associated with the alternative.

An alternative would be to use the Archive Toolbox plug-in from SiteCraft to compress the files before opening the hosted solution (and expand them again afterwards) but this would be more time-intensive especially if the files are sizeable.