An Essbase object is simply a file (in 8 by 3 alphanumberic character format) Essbase uses, such as a database outline, a calc script, or other data.Essbase has an object system which allows you to refer to such files through the API simply by the name, the file type, and the application and database with which they are associated. This allows objects to be manipulated independently of the underlying file system (which may vary between different platforms and implementations of Essbase).
Objects can reside on any Essbase Server or client, and can be copied between them. A locking mechanism on the server controls access to objects, so that users with sufficient privilege can lock server objects and copy them to the client (using the EssGetObject() function), edit them, and save them back to the server (using the EssPutObject() function). Server objects can also be opened without locking for read-only access, but then cannot be saved back to the server. A user can also create or edit objects on client workstations for their personal use, or save them to the server for other users to share.
When you access objects through the API, the object name refers to the file name of the object (without an extension). The object types are declared in the API header file in the form ESS_OBJTYPE_xxx (where xxx represents the specific type, as in ESS_OBJTYPE_REPORT). Most objects are associated with an application and database, but some objects such as calc scripts and rules files can be stored at the application level and used with any database within the application.
Database outline files are different from other objects, and cannot be deleted, renamed, copied, or saved using the API.
Server object files are physically located in the corresponding application or database sub-directory. However, it is not generally advisable to manipulate server object files directly. Always use the appropriate API functions to copy the files locally.
Client object files are also stored by default in application and database sub-directories of the directory specified by the LocalPath setting of ESS_INIT_T. You can freely manipulate and edit these files, but you should ensure your program is well-behaved when locking and unlocking server objects which are being edited on the client (always lock an object before editing and unlock it afterwards, whether or not changes are saved).
You can bypass the client object system and go directly to the file system by setting the application and database to NULL. This makes the object field the entire path.
If you intend to access file objects on a client machine through the API, you need to create alocal context handle for the API object functions to use. To create a local context, use the EssCreateLocalContext function, which returns a context handle. This handle can be passed to any of the object API functions instead of a login context handle, and causes the API to perform the requested operation on the local client object system instead of the server. You only need to create a local context once, immediately after your program first initializes the API.
If you create a local context, your program should clean up by calling the EssDeleteLocalContext function before terminating the API.