Abstract: Systems and methods are described that facilitate idempotent execution of commands generated by a client for execution by a database server. Each command transmitted to the server includes a command ID generated by the client. The server attempts to execute each command and subsequently stores the command ID associated therewith in a repository along with an indication of whether the command executed successfully. When a new command is received by the server, it determines if the command ID associated therewith has already been stored in the repository. If the command ID associated with the new command has not already been stored in the repository, then the server executes the new command. If the command ID associated with the new command has already been stored in the repository and a previously-received command associated with the command ID has been executed successfully, then the server will not execute the new command.

Abstract: A database server includes logic that is operable to monitor and analyze at least events occurring within an environment of the database server and/or execution errors generated by the database server in order to detect whether a problem condition exists. The database server further includes logic that is operable to send one or more commands to a database driver of a client that is communicatively connected to the database server, the one or more commands specifying one or more actions to be taken by the database driver in response to the existence of the problem condition. The database driver includes logic that is operable to receive the one or more commands from the database server and logic that is operable to cause the one or more commands to be executed.

Abstract: A database server includes logic that is operable to monitor and analyze at least events occurring within an environment of the database server and/or execution errors generated by the database server in order to detect whether a problem condition exists. The database server further includes logic that is operable to send one or more commands to a database driver of a client that is communicatively connected to the database server, the one or more commands specifying one or more actions to be taken by the database driver in response to the existence of the problem condition. The database driver includes logic that is operable to receive the one or more commands from the database server and logic that is operable to cause the one or more commands to be executed.

Abstract: Systems and methods are described that establish and maintain a virtual session between a client and one or more database servers. A database server establishes a first session with a client wherein establishing the virtual session with the client comprises associating a virtual session identifier (ID) with the first session, generates state information in association with the first session, and stores the state information in a repository in association with the virtual session ID. After the first session fails, a same or different database server establishes a second session with the client wherein establishing the second session with the client comprises receiving the virtual session ID from the client, accesses the state information that was stored in the repository in association with the virtual session ID, and associates the state information with the second session.

Abstract: A database server includes logic that is operable to monitor and analyze at least events occurring within an environment of the database server and/or execution errors generated by the database server in order to detect whether a problem condition exists. The database server further includes logic that is operable to send one or more commands to a database driver of a client that is communicatively connected to the database server, the one or more commands specifying one or more actions to be taken by the database driver in response to the existence of the problem condition. The database driver includes logic that is operable to receive the one or more commands from the database server and logic that is operable to cause the one or more commands to be executed.

Abstract: Aspects of the subject matter described herein relate to database access. In aspects, a request for access to a database is received at a node of a database cluster. Also received at the node is an intent associated with the request. If the intent is to potentially write to the database, a primary instance of the database services the request. If the intent is to read from but not write to the database, an identifier of a secondary instance of the database is sent to the requestor for use in accessing the database.

Abstract: Systems and methodologies that enhance a Tabular Data Stream (TDS) protocol by enabling efficient transmission of a row(s) with null columns(s). An identification component employs a bit map that can be positioned at beginning of a row, to indicate to the receiving side (e.g., a client) columns that are to be sent. Accordingly, by distinguishing columns that are null from columns that are not null—followed by sending columns that are not null—transmission resources can be effectively employed.

Abstract: A request for application information can be received from an application running in a process. The application information can be requested from an information repository, and received back from the repository in a first format. The application information can be converted to a second format, and passed to the application in the second format. In addition, the application information can be saved in the second format in a cache in the process. Also, when application information has been cached in response to a request for the information for a first user object, and a subsequent request for the application information for a second user object is received, it can be determined whether the second user object is authorized to access the application information. If so, then the application information can be fetched from the cache and returned for use by the second user object.

Abstract: A database server includes logic that is operable to monitor and analyze at least events occurring within an environment of the database server and/or execution errors generated by the database server in order to detect whether a problem condition exists. The database server further includes logic that is operable to send one or more commands to a database driver of a client that is communicatively connected to the database server, the one or more commands specifying one or more actions to be taken by the database driver in response to the existence of the problem condition. The database driver includes logic that is operable to receive the one or more commands from the database server and logic that is operable to cause the one or more commands to be executed.

Abstract: Systems and methods are described that establish and maintain a virtual session between a client and one or more database servers. A database server establishes a first session with a client wherein establishing the virtual session with the client comprises associating a virtual session identifier (ID) with the first session, generates state information in association with the first session, and stores the state information in a repository in association with the virtual session ID. After the first session fails, a same or different database server establishes a second session with the client wherein establishing the second session with the client comprises receiving the virtual session ID from the client, accesses the state information that was stored in the repository in association with the virtual session ID, and associates the state information with the second session.

Abstract: Systems and methods are described that facilitate idempotent execution of commands generated by a client for execution by a database server. Each command transmitted to the server includes a command ID generated by the client. The server attempts to execute each command and subsequently stores the command ID associated therewith in a repository along with an indication of whether the command executed successfully. When a new command is received by the server, it determines if the command ID associated therewith has already been stored in the repository. If the command ID associated with the new command has not already been stored in the repository, then the server executes the new command. If the command ID associated with the new command has already been stored in the repository and a previously-received command associated with the command ID has been executed successfully, then the server will not execute the new command.

Abstract: Aspects of the subject matter described herein relate to database access. In aspects, a request for access to a database is received at a node of a database cluster. Also received at the node is an intent associated with the request. If the intent is to potentially write to the database, a primary instance of the database services the request. If the intent is to read from but not write to the database, an identifier of a secondary instance of the database is sent to the requestor for use in accessing the database.

Abstract: A request for application information can be received from an application running in a process. The application information can be requested from an information repository, and received back from the repository in a first format. The application information can be converted to a second format, and passed to the application in the second format. In addition, the application information can be saved in the second format in a cache in the process. Also, when application information has been cached in response to a request for the information for a first user object, and a subsequent request for the application information for a second user object is received, it can be determined whether the second user object is authorized to access the application information. If so, then the application information can be fetched from the cache and returned for use by the second user object.

Abstract: Systems and methodologies that enhance a Tabular Data Stream (TDS) protocol by enabling efficient transmission of a row(s) with null columns(s). An identification component employs a bit map that can be positioned at beginning of a row, to indicate to the receiving side (e.g., a client) columns that are to be sent. Accordingly, by distinguishing columns that are null from columns that are not null—followed by sending columns that are not null—transmission resources can be effectively employed.

Abstract: Systems and methodologies that enhance a Tabular Data Stream (TDS) protocol by enabling clients to send tabular formed data as a single parameter to servers. A Table Valued Parameter (TVP) transporting component enables the client servers to transmit entire database tables as a single parameter; when invoking a server side procedure, for example. As such, values can be passed for functions associated with a stored procedure, and a parameter styled Application Program Interface (API) can be implemented.