Skip to content

fix long column data fetching #490

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
NGrey5 wants to merge 1 commit into
base: main
Choose a base branch
from
+5 −1
Open

fix long column data fetching #490

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions src/odbc.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -210,6 +210,7 @@ typedef struct StatementData {
SQLUINTEGER fetch_size;
SQLULEN rows_fetched;
bool result_set_end_reached = false;
bool has_long_data = false;

bool fetch_array = false;

Expand Down
5 changes: 4 additions & 1 deletion src/odbc_connection.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3430,7 +3430,7 @@ fetch_and_store(StatementData* data, bool set_position, bool* alloc_error) {
// iterate through all of the rows fetched (but not the fetch size)
for (size_t row_index = 0; row_index < data->rows_fetched; row_index++) {
if (set_position && data->get_data_supports.block &&
data->fetch_size > 1) {
data->fetch_size > 1 && data->has_long_data) {

@kadler kadler Sep 14, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The order of this is confusing since we're only setting the flag after this check, but this basically just always skips SQLSetPos for the first row. We shouldn't need to call SQLSetPos on the first row and by the second row we'll have set it, so that should work despite being a bit confusing.

// In case the result set contains columns that contain LONG data
// types, use SQLSetPos to set the row we are transferring bound data
// from, and use SQLGetData in the same loop.
Expand Down Expand Up @@ -3460,6 +3460,9 @@ fetch_and_store(StatementData* data, bool set_position, bool* alloc_error) {
// SQLBindCol, and therefore there is no data to move from a buffer.
// Instead, call SQLGetData, and adjust buffer size accordingly
if (data->columns[column_index]->is_long_data) {
// Set the statement data as having long data
data->has_long_data = true;
Comment on lines +3463 to +3464

@kadler kadler Sep 14, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To reduce confusion, I think this should be moved into bind_buffers wherever we set is_long_data = true. This also means we don't have to set this value for every row, but only once per long data column.


SQLPOINTER target_buffer;
SQLLEN buffer_size =
data->query_options.initial_long_data_buffer_size;
Expand Down