Skip to content

Conversation

@ucko
Copy link
Contributor

@ucko ucko commented Jul 3, 2024

These were helpful in crafting 3176598 and #595.

ucko added 2 commits July 3, 2024 15:10
... for comparison purposes.

* sqldb.h: Don't insist on the accompanying sybdb.h, which might clash
  with Sybase headers or result in skew with Sybase libraries.
* sqlfront.h: Likewise for sybfront.h; moreover, additionally pull in
  sybdb.h and don't rely on having USHORT.
* ctlib tests: Use centrally defined UT_{CS,BLK}_VERSION macros rather
  than hardcoding {CS,BLK}_VERSION_100, which could result in
  blk_describe failure when run against modern servers.  Allow both to
  be overridden, but default UT_CS_VERSION to CS_CURRENT_VERSION where
  available (falling back on CS_VERSION_160) and UT_BLK_VERSION to
  UT_CS_VERSION because the numbers always match up in practice.

Signed-off-by: Aaron M. Ucko <ucko@ncbi.nlm.nih.gov>
They don't enforce specific results, just note them all in tabular
form to facilitate comparison with Sybase libraries' behavior.

Signed-off-by: Aaron M. Ucko <ucko@ncbi.nlm.nih.gov>
@mmcnabb-vms
Copy link
Contributor

mmcnabb-vms commented Dec 8, 2025

When run against MSSQL 15.0.2155.2, after rebasing to master:

  • Test d_bcp3 goes into infinite loop at while (dbresults(dbproc) != NO_MORE_RESULTS) in bcp3.c ; the dbresults function returns 0 (FAIL) ; the connection was put into an error state by the test. This while-loop pattern is actually used in several places in the test suite, it probably should be fixed to not give infinite loops in case of error (e.g. could we check for equality with expected value(s) instead?)
  • After fixing that, the test reports error message about the stream error state and exits the test with a successful status (I don't think this is intended - there would also need to be code added to log error messages when dbresults(dbproc) returned failure))

@mmcnabb-vms
Copy link
Contributor

mmcnabb-vms commented Dec 8, 2025

Test c_blk_in3 takes prohibitively long to run, against a remote database -- against ASE 16.0 with about 200ms ping latency, it took 9 minutes to complete half of the first of what appears to be about 20 rounds of tests. The test coverage is extremely detailed, and each case starts with a blk_init which means 2 round trips to retrieve the table structure.

To make this test viable (with remote database) we might need to come up with a way of optimizing repeated blk_init() calls.

Against local MSSQL 15.0.2155.2 , a stream error occurs on one of the early tests, and the test exits with a success status.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants