|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
Whenever SF_Flags are required the following table applies:
||read only mode for the
||write only mode
||The stream/storage is fully
shared - can be opened by other applications in any mode
||Read is forbidden for the other
||Write is forbidden for the
||Other applications will receive
an error if any attempt is made to open the same object
||OLE Files only - commit
operations of the other applications will not occur until the
object is opened in priority mode.
(Can be used in CreateXXX methods)
||If the stream/file/storage
exists it will be deleted and a new one will be created
||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
||Creation will fail if the
object already exists.
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.
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
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.