Diagnostics in interrupted fetches

[matthew-wozniczka]

When a fetch gets interrupted with SQL_DATA_AVAILABLE/SQL_METADATA_CHANGED/SQL_MORE_DATA, do any warnings or errors (in the case of multi-row fetches) get returned immediately as they are generated (i.e. are they retrievable via SQLGetDiagField immediately after SQLFetch(Or SQLNextColumn in the case of a fetch which gets interrupted multiple times)), or should they be cached internally in the driver until the fetch completes (SQLNextColumn returns SQL_SUCCESS/SQL_SUCCESS_WITH_INFO/SQL_ERROR)?

[matthew-wozniczka]

The upside to caching them until the end is that the application would be able to directly inspect the problematic cells at the time that they received the diagnostics, instead of having to cache the diagnostics in the application.

Another way to accomplish the same thing would be for us to provide the application a mechanism to allow it to inspect cells which have already been fetched after the fetch was interrupted (something like SQL_DATA_UNAVAILABLE?)

[mikepizzo]

Possible effect on DM state transitions?

[mikepizzo]

I would prefer that the diagnostics get cached until the fetch completes. This gives a simpler experience for inspecting the result of the completed fetch. Alternative would be to add SQL_SUCCESS_WITH_INFO to SQLNextColumn and require the application to process issues so far, understanding (as you say) which random fields had/had not been populated, which doesn't seem very friendly.

[mikepizzo]

Clarified that diagnostic information for the fetch (like bound values) may not be available until the fetch completes.