-
Notifications
You must be signed in to change notification settings - Fork 3.9k
GH-46575: [C++][FlightRPC] ODBC Diagnostics Report #47763
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.
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
base: main
Are you sure you want to change the base?
Conversation
|
fe98d28
to
8d1b940
Compare
Co-Authored-By: rscales <[email protected]>
8d1b940
to
0c8fddc
Compare
@lidavidm @kou Please review this draft ODBC API PR. The test PR is at #47764.
|
// The length of the sql state is always 5 characters plus null | ||
SQLSMALLINT size = 6; | ||
const std::string& state = diagnostics->GetSQLState(record_index); | ||
GetStringAttribute(is_unicode, state, false, sql_state, size, &size, *diagnostics); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we not need to check the return value?
SQLSMALLINT* string_length_ptr, bool is_unicode) { | ||
const SQLSMALLINT char_size = is_unicode ? GetSqlWCharSize() : sizeof(char); | ||
const bool has_valid_buffer = | ||
diag_info_ptr && buffer_length >= 0 && buffer_length % char_size == 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need diag_info_ptr &&
here?
diag_info_ptr && buffer_length >= 0 && buffer_length % char_size == 0; | |
buffer_length >= 0 && buffer_length % char_size == 0; |
Rationale for this change
ODBC needs to provide diagnostic information so users can debug the error
What changes are included in this PR?
Tests are included in separate PR (see GH-46575: [C++][FlightRPC] Add Diagnostic tests #47764)
Are these changes tested?
The build will be checked in CI when PR is ready for review.
Tests will be in a separate PR (see #47764). Other APIs depend on SQLGetDiagField and SQLGetDiagRec to get error reporting functionality, and tests for SQLGetDiagField and SQLGetDiagRec depend on other APIs for creating errors, as these diagnostic APIs alone do not initiate any errors.
Are there any user-facing changes?
No