Abstract: The present invention extends to methods, systems, and computer program products for using directory historical data to facilitate automated file updates. A pair of directories is updated, for example, synchronized, with one another. Directory historical data, such as, for example, previous contents of the directories, is utilized to determine what file operations are to be performed during an update. User-selectable update modes can also be used to further configure what file operations are performed during an update.

Abstract: The present invention extends to methods, systems, and computer program products for extending non-volatile storage at a computer system. In some embodiments, a file operation is performed on at least one shadow copy of a file that is perceived by an application to be stored on a single volume. A plurality of shadow copies of a file can be accessed using durable file identifiers that are durable across changes to other file characteristics. It is indicated back to the application that the file operation was performed on the file perceived to be stored on the single volume. Storage capabilities are enhanced through migration and/or replication of files to newly added volumes.

Abstract: The present invention extends to methods, systems, and computer program products for extending non-volatile storage at a computer system. In some embodiments, a file operation is performed on at least one shadow copy of a file that is perceived by an application to be stored on a single volume. A plurality of shadow copies of a file can be accessed using durable file identifiers that are durable across changes to other file characteristics. It is indicated back to the application that the file operation was performed on the file perceived to be stored on the single volume. Storage capabilities are enhanced through migration and/or replication of files to newly added volumes.

Abstract: The present invention extends to methods, systems, and computer program products for using directory historical data to facilitate automated file updates. A pair of directories is updated, for example, synchronized, with one another. Directory historical data, such as, for example, previous contents of the directories, is utilized to determine what file operations are to be performed during an update. User-selectable update modes can also be used to further configure what file operations are performed during an update.

Abstract: An application layer protocol is provided on top of HTTP 1.0/1.1 to allow for COM Automation objects to be invoked over the Internet through IIS/ISAPI servers. The format essentially encodes the automation object's name, method to invoke, and any [in], [out], [in, out] parameters that the method signature requires, packages them up into a custom MIME type and marshals it to the ISAPI dynamic link library (DLL) on the IIS/HTTP server. There, the ISAPI DLL contains the logic to unpack the SOAP request, parses it, creates the Automation object, invokes the method with the marshaled parameters, and then returns any [out] parameters to the caller/client using the SOAP protocol. It is a stateless protocol, meaning that object lifetimes only extend to one method, and are recreated between multiple calls to the object.

Abstract: An application layer protocol is provided on top of HTTP 1.0/1.1 to allow for COM Automation objects to be invoked over the Internet through IIS/ISAPI servers. The format essentially encodes the automation object's name, method to invoke, and any [in], [out], [in, out] parameters that the method signature requires, packages them up into a custom MIME type and marshals it to the ISAPI dynamic link library (DLL) on the IIS/HTTP server. There, the ISAPI DLL contains the logic to unpack the SOAP request, parses it, creates the Automation object, invokes the method with the marshaled parameters, and then returns any [out] parameters to the caller/client using the SOAP protocol. It is a stateless protocol, meaning that object lifetimes only extend to one method, and are recreated between multiple calls to the object.

Abstract: An application layer protocol is provided on top of HTTP 1.0/1.1 to allow for COM Automation objects to be invoked over the Internet through IIS/ISAPI servers. The format essentially encodes the automation object's name, method to invoke, and any [in], [out], [in, out] parameters that the method signature requires, packages them up into a custom MIME type and marshals it to the ISAPI dynamic link library (DLL) on the IIS/HTTP server. There, the ISAPI DLL contains the logic to unpack the SOAP request, parses it, creates the Automation object, invokes the method with the marshaled parameters, and then returns any [out] parameters to the caller/client using the SOAP protocol. It is a stateless protocol, meaning that object lifetimes only extend to one method, and are recreated between multiple calls to the object.

Abstract: An in-memory database system uses a shared memory to cache records and keys read from a database and controls the updating of the records and keys through a database manager process. When a transaction performs an update, the original, unmodified data is preserved in the shared memory, the new data is written to the shared memory, and a look-aside table for the transaction records the changes. A transaction performs read-only access to the shared memory using its own context while a versioning scheme based on the look-aside tables ensures a read-committed isolation level view of the original, unmodified data until the modifying transaction commits the update. The database manager is responsible for writing the new data into the shared memory and for maintaining the look-aside tables for all transaction which have made modifications to the data in the shared memory.

Abstract: An in-memory database system uses a shared memory to cache records and keys read from a database and controls the updating of the records and keys through a database manager process. When a transaction performs an update, the original, unmodified data is preserved in the shared memory, the new data is written to the shared memory, and a look-aside table for the transaction records the changes. A transaction performs read-only access to the shared memory using its own context while a versioning scheme based on the look-aside tables ensures a read-committed isolation level view of the original, unmodified data until the modifying transaction commits the update. The database manager is responsible for writing the new data into the shared memory and for maintaining the look-aside tables for all transaction which have made modifications to the data in the shared memory.

Abstract: An improved method and system for binding data is provided. In a preferred embodiment of the present invention, bound controls transfer data to cursors through a binding manager. The binding manager is also responsible for transferring data from a cursor to a bound control. In addition, a preferred embodiment of the present invention provides for a notification mechanism as part of the cursor. The notification mechanism of the cursor of the preferred embodiment provides synchronization amongst all binding managers utilizing the cursor. The notification mechanism of the preferred embodiment provides synchronization amongst all binding managers by invoking event handlers registered by the binding managers. The event handlers are invoked by the cursor both before and after an operation is performed by the cursor.