On FlexODBC v4.00.19 the read-only file "FQDF.SEC" appears to be always open. Even when there is no active ODBC session. And even when no security is required (i.e. no user login). Having a file open within the DataFlex "data" directory interferes with backup operations (even though no workstation has any DataFlex table open).

With no open DataFlex tables, and no application which uses FlexODBC running, the "FQDF.SEC" file still remains open. And if deleted then a new one immediately gets recreated.

Is there any way to eliminate the use of the "FQDF.SEC" file? Or is there a way to force a close of the file?

FQDF.SEC is created if one does not exists in the same folder where filelist.cfg is found each time FlexODBC is used. There is no turning it off. The default FQDF.SEC just grants permission for everything to everyone. The user has to take away rights to make it "On" (to switch the security feature on).

When using FlexODBC in default mode, FQDF.SEC can be deleted at any point of time.

Thanks for confirming "There is no turning it off." However, although "When using FlexODBC in default mode, FQDF.SEC can be deleted at any point of time" may be true, my testing shows that it is immediately recreated -- even if there are no applications which use either DataFlex or FlexODBC running on any workstation.

My test configuration is (1) server under Win2K with DataFlex database files, including "filelist.cfg", (2) one WinXP workstation with FlexODBC installed (with default security), but no application using either DataFlex or FlexODBC running and (3) one Win2K workstation with a DataFlex application (but not FlexODBC) installed, but no DataFlex application running.

In this situation the open, read-only "FQDF.SEC" file can be deleted on the server, but re-appears within a second as a new, open, read-only file. Now the issue is not the presence of the file, it is the fact that Windows 2000 shows the "FQDF.SEC" file as open that interferes with backups. So I must ask again:

• Is there a way to force "FQDF.SEC" closed?

Thus far, the only way I have found to address this issue is to de-activate FlexODBC on the workstation where it is installed and then delete "FQDF.SEC" on the server.

No, the data folder should always be read/write. FlexODBC can be set to operate in read-only mode if required instead.

"Because the data is on your Win2K file server, any workstation can create FQDF.SEC, even if you just run the FlexODBC Setup Screen or configure a DSN. Maybe there's a logged out user session that still running FlexODBC on your server?"

There is only one (1) workstation with FlexODBC installed. FlexODBC setup was not run after deleting FQDF.SEC file, nor was a DSN configured. Also there was no application which used FlexODBC (or the DSN) running on the only workstation with FlexODBC installed. But the file FQDF.SEC kept appearing after each delete.

The only way that I could eliminate FQDF.SEC was to deactivate FlexODBC on the only workstation where it was installed. Until there is some way to eliminate this issue (i.e. a way to assure that FQDF.SEC is not "open" -- read-only is not an issue -- when FlexODBC is not in use by any application) we will not be able to justify use of the product. This issue arose during feasibility testing and appears to make FlexODBC unsuitable for our use.