Abstract: Techniques for recovering from session failures between clients and database servers are described herein. A session may be established between a client and a first database server to handle a database query for the client. A command of the session may be received by the first database server from the client. Data requested by the command may be retrieved. Prior to responding to the command, the data is spooled to a session state stored in a repository of the first database server, and the session state is replicated to one or more additional database servers. The session state stored in the repository of the first database server enables the first database server and client to recover from a failure of the session. The replicated session state enables the additional database server(s) to reestablish the session and respond to the command, instead of the first database server, if the session fails.

Abstract: Techniques for recovering from session failures between clients and database servers are described herein. A session may be established between a client and a first database server to handle a database query for the client. A command of the session may be received by the first database server from the client. Data requested by the command may be retrieved. Prior to responding to the command, the data is spooled to a session state stored in a repository of the first database server, and the session state is replicated to one or more additional database servers. The session state stored in the repository of the first database server enables the first database server and client to recover from a failure of the session. The replicated session state enables the additional database server(s) to reestablish the session and respond to the command, instead of the first database server, if the session fails.

Abstract: Techniques for recovering from session failures between clients and database servers are described herein. A first session may be established between a client and a first database server to handle a database query for the client. A request for data associated with the first session may be received by the first database server from the client, and the data retrieved. Prior to responding to the request, the data is spooled to a first session state stored in a repository made accessible by at least one computing device. The computing device(s) controls access to session states in the repository that correspond to sessions between clients and database servers. The computing device(s) enables sessions to be reestablished between the clients and database servers by accessing data of the session states in the repository and transmitting the data in response to messages received from the database servers containing session identifiers.

Abstract: Techniques for recovering from session failures between clients and database servers are described herein. A session may be established between a client and a first database server to handle a database query for the client. A command of the session may be received by the first database server from the client. Data requested by the command may be retrieved. Prior to responding to the command, the data is spooled to a session state stored in a repository of the first database server, and the session state is replicated to one or more additional database servers. The session state stored in the repository of the first database server enables the first database server and client to recover from a failure of the session. The replicated session state enables the additional database server(s) to reestablish the session and respond to the command, instead of the first database server, if the session fails.

Abstract: Techniques for recovering from session failures between clients and database servers are described herein. A session may be established between a client and a first database server to handle a database query for the client. A command of the session may be received by the first database server from the client. Data requested by the command may be retrieved. Prior to responding to the command, the data is spooled to a session state stored in a repository of the first database server, and the session state is replicated to one or more additional database servers. The session state stored in the repository of the first database server enables the first database server and client to recover from a failure of the session. The replicated session state enables the additional database server(s) to reestablish the session and respond to the command, instead of the first database server, if the session fails.

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: Techniques for recovering from session failures between clients and database servers are described herein. A session may be established between a client and a first database server, and a transaction may be opened to process a plurality of database commands. One or more commands associated with the transaction may be received from the client at the database server. Each received command has an associated command identifier. A transaction log stores the command identifier associated with each received command and indicates whether each received command has been successfully executed at the database server. After a session failure, the session is reestablished, and a command identifier for a further command is received from the client. If the command identifier associated with the further command is determined to have been stored in the transaction log, the command does not need to be executed, and the transaction may continue.

Abstract: A first computer utilizes a logical connection with a second computer. The logical connection comprises multiple physical network connections using multiple physical network devices on the first computer. Two or more of the physical network devices of a logical connection are used to transfer packets of a single data transfer such as a database request or response. A logical connection can include a single physical network device on the second computer creating a one-to-many logical connection or may also include multiple physical network devices on the second computer creating a many-to-many logical connection.

Abstract: Techniques for recovering from session failures between clients and database servers are described herein. A session may be established between a client and a first database server, and a transaction may be opened to process a plurality of database commands. One or more commands associated with the transaction may be received from the client at the database server. Each received command has an associated command identifier. A transaction log stores the command identifier associated with each received command and indicates whether each received command has been successfully executed at the database server. After a session failure, the session is reestablished, and a command identifier for a further command is received from the client. If the command identifier associated with the further command is determined to have been stored in the transaction log, the command does not need to be executed, and the transaction may continue.

Abstract: Techniques for recovering from session failures between clients and database servers are described herein. A session may be established between a client and a first database server to handle a database query for the client. A command of the session may be received by the first database server from the client. Data requested by the command may be retrieved. Prior to responding to the command, the data is spooled to a session state stored in a repository of the first database server, and the session state is replicated to one or more additional database servers. The session state stored in the repository of the first database server enables the first database server and client to recover from a failure of the session. The replicated session state enables the additional database server(s) to reestablish the session and respond to the command, instead of the first database server, if the session fails.

Abstract: A first computer establishes a logical connection to a second computer for requesting and/or receiving data from a database. A logical connection is independent of the underlying physical network connection used to connect to the database. A context identifier is stored by both computers to enable the context of a logical connection to be persisted between switches from one physical network connection to another within the logical connection thus enabling database transfers to be continued on a second physical network connection when a failure in a first physical network connection occurs.

Abstract: A data transfer is received and processed out of order based on contextual information provided by the sending computer. Individual packets within a data transfer are marked as requiring in order processing while the remaining packets of the data transfer are processed out of order. The packets may be labeled with a sequential identifier to enable the receiving computer to determine the proper ordering of packets that require in order processing.

Abstract: A first computer utilizes a logical connection with a second computer. The logical connection comprises multiple physical network connections using multiple physical network devices on the first computer. Two or more of the physical network devices of a logical connection are used to transfer packets of a single data transfer such as a database request or response. A logical connection can include a single physical network device on the second computer creating a one-to-many logical connection or may also include multiple physical network devices on the second computer creating a many-to-many logical connection.

Abstract: A first computer establishes a logical connection to a second computer for requesting and/or receiving data from a database. A logical connection is independent of the underlying physical network connection used to connect to the database. A context identifier is stored by both computers to enable the context of a logical connection to be persisted between switches from one physical network connection to another within the logical connection thus enabling database transfers to be continued on a second physical network connection when a failure in a first physical network connection occurs.

Abstract: Systems and methods are provided, wherein the method includes retrieving and/or storing one or more data types representative of a selected date and/or time value from a server to a client in a server/client SQL environment using a selected wire format. Another aspect provides apparatus including a SQL server, a SQL client operationally coupled to the server, and means to transmit the selected time/date data types between the server and the client according to a selected wire format. In an illustrative implementation, the wire format translates the date/time data into a binary format.

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.