Storages & Files SFFlags
All the Storage and Stream related objects use common flags where it is possible. Also all the default values for the optional parameters are the same for all the methods.

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:

Flag name Flag value Meaning
Open/create mode flags
cSFRead &H00000000 read only mode for the stream/storage 
cSFWrite &H00000001 write only mode
cSFReadWrite &H00000002 read/write mode
cSFShareDenyNone &H00000040 The stream/storage is fully shared - can be opened by other applications in any mode 
cSFShareDenyRead &H00000030 Read is forbidden for the other applications.
cSFShareDenyWrite &H00000020 Write is forbidden for the other applications.
cSFShareExclusive &H00000010 Other applications will receive an error if any attempt is made to open the same object (storage/stream/file/directory etc.)
cSFSharePriority &H00040000 OLE Files only - commit operations of the other applications will not occur until the object is opened in priority mode.
Creation specific (Can be used in CreateXXX methods)
cSFCreate &H00001000 If the stream/file/storage exists it will be deleted and a new one will be created
cSFConvert &H00020000 Supported by some storage implementations only (OLE files for example) convert the file to a part of the storage (see MSDN for more details - see STGM enumeration). 
cSFFailIfThere &H00000000 Creation will fail if the object already exists.
Transactioning (if supported - OLE Files)
These flags are rarely useful for scripting applications. For information on the transaction control flags see MSDN (STGM enumeration).

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.

newObjects Copyright 2001-2006 newObjects [ ]