The flags are supported by Open/Create methods. This concerns the SFMain (OpenFile, CreateFile, OpenDirectory, CreateDirectory, OpenStorageFile etc.), SFStorage (OpenStoage, CreateStorage, OpenStream etc.), SFFileStream and SFDirStorage.

Whenever SF_Flags are required the following table applies:

In all the methods where SF_Flags are expected they are optional. If omitted the default value used is &H12 (0x12) which means: open exclusive for read and write. Please note that exclusive access is default! If you need more than one applications/pages to share the same resource you will need to specify flags explicitly or share one single SFStorage/SFStream object between the applications.

Sharing techniques

In general there are two ways to implement resource (file/storage/stream) sharing in the applications:

• By using appropriate flags.
• Or by sharing one SFStorage or SFStream object attached to the resource between the applications.

The first technique is always applicable but depends on the implementation of the sharing mechanisms in the OS or the custom objects that manage the resource (s). It is quite good technique for files and OLE storages, but can be inefficient for some applications. This technique will require code to handle the read/write errors caused by sharing violations.

The second technique serializes all the operations through the SF object and thus always guarantees that only one operation with the resource will be in progress at a time. However it is suitable only for environments where objects can be easilly passed between the applications. For example this is quite simple in ASP (using Application). The free threaded version of the component is recommended.

Note for ASP developers. While in IIS you have only one instance of the ASP engine in ALP the user is able to start several separate copies of the application running in isolated processes. If they use the same resource through SF objects the second instance (and any subsequent instances) of the application may be unable to access it if it is already opened by the first running instance in exclusive mode. However preventing the subsequent instances from accessing the resource can be a good way to guarantee the resource consistency. To inform user put some error handling code in the initialization part of the application to inform him/her that the resource is locked by other application/instance of the same app. and he/she should work with it instead of starting a new copy.