---
sidebar_position: 1
---

# OkPacket

`Object`

The OkPacket is a response object from MySQL that provides metadata about a successfully executed query. It contains details such as the number of affected rows, insert IDs, server status, warnings, and protocol information. This packet is typically returned for INSERT, UPDATE, DELETE, and other non-SELECT statements.

## Structure

| Property | Type | Description |
| -- | -- | -- |
| `fieldCount` | __Number__ | Defaults to 0 on non-select queries |
| `affectedRows` | __Number__ | The number of rows affected by the query. Does not mean all rows were changed |
| `insertId` | __Number__ | The ID of the last inserted row if the table has an auto-increment column; otherwise always 0 |
| `serverStatus` | __Number__ | A status flag representing the current state of the mysql server |
| `warningCount` | __Number__ | The number of warnings generated during query execution |
| `message` | __String__ | An optional message providin additional information about the query result (normally empty) |
| `protocol41` | __Boolean__ | Whether mysql protocol 4.1 or later is used |
| `changedRows` | __Number__ | The number of rows actually changed by the query |

## Common serverStatus

:::info `serverStatus` is a bitmask
This means multiple statuses can be set at the same time. For example, if `SERVER_STATUS_AUTOCOMMIT` (__1__) and `SERVER_STATUS_IN_TRANS` (__2__) are both active, the `serverStatus` value will be the combination of the corresponding bits (bitwise OR operation). It therefore will become __3__
:::

| `serverStatus`-Value | Status | Description |
| -- | -- | -- |
| __1__ | `SERVER_STATUS_AUTOCOMMIT` | The server is in autocommit mode, meaning each query is treated as a single transaction and is automatically committed |
| __2__ | `SERVER_STATUS_IN_TRANS` | The server is in a transaction. This means that queries are being executed within an open transaction, and they have not been committed yet |
| __8__ | `SERVER_STATUS_MORE_RESULTS_EXISTS` | There are more result set available. This status is seen when a `SELECT` query returns multiple result sets (e.g., when using `SELECT ... INTO OUTFILE`) |
| __16__ | `SERVER_STATUS_NO_GOOD_INDEX_USED` | The server did not use a good index for the query. This might indicate a suboptimal query execution, such as using a less efficient index for the query |
| __32__ | `SERVER_STATUS_NO_INDEX_USED` | The server did not use any __index__ for the query, which may lead to slower performance due to a full table scan |
| __64__ | `SERVER_STATUS_QUERY_NO_GOOD_INDEX_USED` | Indicates that no suitable index was used during the query execution, potentially resulting in performance issues |
| __128__ | `SERVER_STATUS_CURSOR_EXISTS` | A __cursor__ exists and is used for the query. This status is relevant for more complex queries or when cursors are used for querying |
| __256__ | `SERVER_STATUS_LAST_INSERT_ID` | This status indicates that the __last__ `INSERT` __statement__ generated an `AUTO_INCREMENT` ID. It is important for `INSERT` queries, as it relates to auto-generated IDs |
| __512__ | `SERVER_STATUS_DB_DROPPED` | This status indicates that a __database was dropped__ |